View PEB20320_8216188.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

ics for communications multichannel network interface controller for hdlc munich32 peb 20320 version 3.4 user?s manual 01.2000 ds3
for questions on technology, delivery and prices please contact the infineon technologies offices in germany or the infineon technologies companies and representatives worldwide: see our webpage at http://www.infineon.com peb 20320 revision history: current version: 01.2000 previous version: user ? s manual 1998-06-01 ds2 (v3.4) page (in previous version) page (in current version) subjects (major changes since last revision) package p-tqfp-176-1 removed from user ? s manual. edition 01.2000 published by infineon technologies ag, sc, balanstra?e 73, 81541 mnchen ? infineon technologies ag 2000. all rights reserved. attention please! as far as patents or other rights of third parties are concerned, liability is only assumed for components, not for applications, processes and circuits implemented within components or assemblies. the information describes the type of component and shall not be considered as assured characteristics. terms of delivery and rights to change design reserved. due to technical requirements components may contain dangerous substances. for information on the types in question please contact your nearest infineon technologies office. infineon technologies ag is an approved cecc manufacturer. packing please use the recycling operators known to you. we can also help you ? get in touch with your nearest sales office. by agreement we will take packing material back, if it is sorted. you must bear the costs of transport. for packing material that is returned to us unsorted or which we are not obliged to accept, we shall have to invoice you for any costs incurred. components used in life-support devices or systems must be expressly authorized for such purpose! critical components 1 of the infineon technologies ag, may only be used in life-support devices or systems 2 with the express written approval of the infineon technologies ag. 1 a critical component is a component used in a life-support device or system whose failure can reasonably be expected to cause the failure of that life-support device or system, or to affect its safety or effectiveness of that device or system. 2 life support devices or systems are intended (a) to be implanted in the human body, or (b) to support and/or maintain and sustain human life. if they fail, it is reasonable to assume that the health of the user may be en- dangered. abm ? , aop ? , arcofi ? , arcofi ? -ba, arcofi ? -sp, digitape ? , epic ? -1, epic ? -s, elic ? , falc ? 54, falc ? 56, falc ? -e1, falc ? -lh, idec ? , iom ? , iom ? -1, iom ? -2, ipat ? -2, isac ? -p, isac ? -s, isac ? -s te, isac ? -p te, itac ? , iwe ? , musac ? -a, octat ? -p, quat ? -s, sicat ? , sicofi ? , sicofi ? -2, sicofi ? -4, sicofi ? -4c, slicofi ? are registered trademarks of infineon technologies ag. ace ? , asm ? , asp ? , potswire ? , quadfalc ? , scout ? are trademarks of infineon technologies ag.
peb 20320 user ? s manual 3 01.2000 preface the multichannel network interface controller for hdlc (munich32) is a multichannel protocol controller for a wide area of telecommunication and data communication applications. organization of this document this user ? s manual is divided into 9 chapters. it is organized as follows: chapter 1, introduction gives a general description of the product and its family, lists the key features, and presents some typical applications. chapter 2, functional description this chapter provides a detailed description of the interfaces and the protocol modes. chapter 3, operational description provides a description of munich32 reset procedure and initialization. chapter 4, detailed register description gives a detailed description of the shared memory organization. chapter 5, application notes chapter 6, application hints chapter 7, electrical characteristics gives a detailed description of all electrical dc and ac characteristics and provides timing diagrams and values for all interfaces. chapter 8, package outlines chapter 9, appendix this chapter provides source code examples. your comments we welcome your comments on this document as we are continuously aiming at improving our documentation. please send your remarks and suggestions by e-mail to sc.docu_comments@infineon.com please provide in the subject of your e-mail: device name (munich32), device number (peb 20320), device version (version 3.4), and in the body of your e-mail: document type (user ? s manual), issue date (01.2000) and document revision number (ds3).
peb 20320 user ? s manual 4 01.2000
peb 20320 table of contents page user ? s manual 5 01.2000 1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 1.1 features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 1.2 pin configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 1.3 pin definitions and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 1.4 logic symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 1.5 functional block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 1.6 system integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 2 functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 2.1 serial interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 2.2 microprocessor interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 2.2.1 intel mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 2.2.2 motorola mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 2.2.3 dma priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 2.3 basic functional principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 2.4 detailed protocol description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 2.5 boundary scan unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 3 operational description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 3.1 reset state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 3.2 initialization procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 4 detailed register description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 4.1 organization of the shared memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 4.2 control and configuration section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 4.2.1 action specification (read once after each action request pulse) . . .136 4.2.2 interrupt queue specification . . . . . . . . . . . . . . . . . . . . . . .140 4.2.3 interrupt information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 4.2.4 time slot assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 4.2.5 channel specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149 4.2.6 current receive and transmit descriptor address . . . . . . . . . . . . . .161 4.3 transmit descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 4.4 receive descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 5 application notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 5.1 test loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 5.1.1 test loop definitions for the munich32 . . . . . . . . . . . . . . . . . . . . . . .173 5.1.1.1 internal complete test loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 5.1.1.2 internal channelwise test loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 5.1.1.3 external complete test loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 5.1.1.4 external channelwise test loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 5.1.2 test loop activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 5.1.3 test loop deactivation and switching . . . . . . . . . . . . . . . . . . . . . . . . . .176 5.1.3.1 software operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
peb 20320 table of contents page user ? s manual 6 01.2000 5.1.3.2 hardware reset operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 5.1.4 test loop examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 5.1.4.1 internal channelwise test loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 5.1.4.2 external channelwise test loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 5.2 munich32 in a lan/wan router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 5.2.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 5.2.2 hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183 5.2.3 software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 5.2.3.1 device driver module munich32 . . . . . . . . . . . . . . . . . . . . . . . . . . .191 5.2.3.2 application module mroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 5.2.4 performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197 5.2.5 final remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 5.2.6 adaption of the 68040 p signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 5.2.7 schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205 5.3 memory bus occupancy for a single munich32 . . . . . . . . . . . . . . . . . . .214 5.3.1 bus occupancy calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 5.3.2 bus occupancy for idle tx channels . . . . . . . . . . . . . . . . . . . . . . . . . .218 6 application hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220 6.1 frequency adaption in an intel 368 common bus system . . . . . . . . . . . .220 6.2 munich32 memory space requirement . . . . . . . . . . . . . . . . . . . . . . . . .223 6.3 serial interface to different pcm systems . . . . . . . . . . . . . . . . . . . . . . . . .224 6.3.1 munich32 for siemens primary access interface . . . . . . . . . . . . . . .224 6.3.2 munich32 in systems with mitel st bus . . . . . . . . . . . . . . . . . . . . .227 7 electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 7.1 absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 7.2 dc characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 7.3 capacitances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 7.4 ac characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 7.5 microprocessor interface intel bus mode . . . . . . . . . . . . . . . . . . . . . . . . .232 7.6 microprocessor interface motorola bus mode . . . . . . . . . . . . . . . . . . . . . .235 8 package outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 9 appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 9.1 source code extract munich32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 9.2 source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
peb 20320 introduction user ? s manual 7 01.2000 1 introduction the multichannel network interface controller for hdlc (munich32) is a multichannel protocol controller, which handles up to 32 data channels of a full duplex pcm highway. it performs layer 2 hdlc formatting/deformatting or v.110 and x.30 protocols up to a network data rate of 38.4 kbit/s as well as transparent transmission for the dmi mode 0, 1 and 2. the processed data is passed on to an external memory shared with one or more host processors. munich32 is compatible with the lapd isdn (integrated services digital network) protocol specified by ccitt as well as with hdlc, sdlc, lapb dmi protocols. it provides any rate adaption for time slot transmission data rate from 64 kbit/s down to 8 kbit/s and the concatenation of any time slots to data channels, supporting the isdn h0, h11, h12 superchannels. due to these functions the munich32 can be used in a wide area of telecommunication and data communication applications, e.g. in central office switches, for the connection of a digital pabx to a host computer, as a central d-channel controller to 32 isdn basic access d-channels or as a multiplexer for terminals and other peripherals. up to 4 munich32s can be connected to one pcm highway, so a d-channel controller with 128 channels can be achieved.
p-mqfp-160-1 user ? s manual 8 01.2000 multichannel network interface controller for hdlc munich32 peb 20320 version 3.4 cmos type package peb 20320 p-mqfp-160-1 1.1 features serial interface ? up to 32 independent communication channels. ? serial multiplexed (full duplex) input/output for 2048-, 4096-, 1544- or 1536-kbit/s pcm highways. dynamic programmable channel allocation ? compatible with t1/ds1 24-channel and cept 32-channel pcm byte format. ? concatenation of any, not necessarily consecutive, time slots to superchannels independently for receive and transmit direction. ? support of h0, h11, h12 isdn-channels. ? subchanneling on each time slot possible. bit processor functions (adjustable for each channel) ? hdlc protocol ? automatic flag detection and transmission ? shared opening and closing flag ? detection of interframe-time-fill change, generation of interframe-time-fill ? 1 ? s or flags ? zero bit insertion ? flag stuffing and flag adjustment for rate adaption ? crc generation and checking (16 or 32 bits) ? transparent crc option per channel and/or per message ? error detection (abort, long frame, crc error, 2 categories of short frames, non-octet frame content) ? special short frame mode to allow reception of ? frames ? with a least on byte length ? abort/idle generation
peb 20320 introduction user ? s manual 9 01.2000 ? v.110/x.30 protocol ? automatic synchronization in receive direction, automatic generation of the synchronization pattern in transmit direction ? e / s / x bits freely programmable in transmit direction, van be changed during transmission; changes monitored and reported in receive direction ? generation/detection of loss of synchronism ? bit framing with network data rates from 600 bit/s up to 38.4 kbit/s ? transparent mode a ? slot synchronous transparent transmission/reception without frame structure ? bit-overwrite with fill/mask bits ? flag generation, flag stuffing, flag extraction, flag generation in the abort case with programmable flag ? transparent mode b ? transparent transmission/reception in frames delimited by 00 h flags ? shared opening and closing flag ? flag stuffing, flag detection, flag generation in the abort case ? error detection (non octet frame content, short frame, long frame) ? transparent mode r ? transparent transmission/reception with gsm 08.60 frame structure ? automatic 0000 h flag generation/detection ? support of 40, 39 1 / 2 , 40 1 / 2 octet frames ? error detection (non octet frame content, short frame, long frame) ? protocol independent ? channel inversion (data, flags, idle code) ? format conventions as in ccitt q.921 2.8 ? data over- and underflow detected processor interface ? on-chip 64-channel dma controller with buffer chaining capability. ? compatible with motorola 68020 processor family and intel 32-bit processor (80386). ? 32 bit data bus and 32 bit address bus (4 gbyte ram addressable, motorola and intel non-parity) or 28 bit address bus (256 mbyte ram addressable, intel parity) ? intel parity mode with data byte parity (4 parity bits) ? parity check for read accesses ? parity generation for write accesses ? interrupt-circular buffer with variable size ? maskable interrupts for each channel ? p interface buffer of depth 16 long words for adaptive bus occupation
peb 20320 introduction user ? s manual 10 01.2000 general ? connection of up to four munich32 supporting a 128-channel basic access d-channel controller. ? on-chip receive and transmit data buffer; the buffer size is 256 bytes each. ? hdlc protocol or transparent mode, support of ecma 102, ccitt i4.63 ra2, v.110, x.30, dmi mode 0, 1, 2 (bit rate adaption), gsm 08.60 trau frames. ? loop mode, complete loop as well as single channel loop ? jtag boundary scan test ? advanced low-power cmos technology ? ttl-compatible inputs/outputs ? 160 pin p-mqfp package
peb 20320 introduction user ? s manual 11 01.2000 1.2 pin configuration (top view) figure 1 itp03487 marking a19 a9 d8 d18 a18 d17 a12 a11 d10 a10 d9 a8 int/int d31 a28/dp0 d28 d27 a27 v ss rsp rdata ci0 i/m ready/dsack hlda/bg bgack/pm hold/br ds/pchk w,r/r;w d30 a30/dp2 a26 d26 d25 d21 a21 d20 a20 index d19 d16 d15 a22 v ss d29 d3 d4 ss v d7 d0 d1 be0 d2 a3 a4 d5 a5 d6 be1 a7 a17 a15 a14 d14 a13 d13 d11 be2 b16 berr ar tsp tclk n.c. hldao/bgo test sclk reset jtest3 jtest2 jtest0 jtest1 n.c. rclk ci1 ci3 ci4 n.c. munich32 peb 20320 v ss v dd d22 ss v ss v v dd d23 a23 d24 a24 v ss v dd a25 v ss v dd v ss v dd a29/dp1 v ss v dd a31/dp3 a16 d12 v dd v ss v dd a6 v dd v ss v ss v dd v v ss ss a2 v dd v ss v dd v ss be3 v dd v ss v ss ads/as v dd v ss n.c. n.c. ci2 tdata n.c. n.c. v ss v dd 1 160 150 140 130 121 10 20 30 40 41 50 60 70 80 100 120 110 81 90 v ss v ss v dd v ss dd v dd v dd v v dd ss v v v ss dd v v ss dd dd v ss v ss v dd v v ss v v dd ss p-mqfp-160-1
peb 20320 introduction user ? s manual 12 01.2000 1.3 pin definitions and functions pin definitions and functions pin no. p-mqfp-160-1 symbol input (i) output (o) function 83, 87, 88, 92, 97, 103, 104, 110, 111, 117, 123, 130, 136, 141, 144, 150, 151, 157, 3, 9, 10, 16, 22, 23, 29, 30, 36, 59, 62, 64, 77 v ss i ground (0 v) all pins must have the same level. 73 i/m i intel bus mode or motorola bus mode by connecting this pin to either v ss or v dd the bus interface can be adapted to either intel or motorola environment. the data is interpreted either in intel or motorola manner; i.e. little or big endian convention. i/m = low: intel bus mode i/m = high: motorola bus mode 39 a31 dp3 o i/o address bit 31 (intel non-parity/motorola) tristate when unused. data parity 3 (intel parity mode), bidirectional tristate line containing/ expecting parity bit of d(31:24). 35 a30 dp2 o i/o address bit 30 (intel non-parity/motorola) tristate when unused. data parity 2 (intel parity mode), bidirectional tristate line containing/ expecting parity bit of d(23:16). note: input pins that are unused in a specific configuration must be strapped to v ss . i/o or output pins that are unused in a specific configuration must be left open!
peb 20320 introduction user ? s manual 13 01.2000 33 a29 dp1 o i/o address bit 29 (intel non-parity/motorola) tristate when unused. data parity 1 (intel parity mode), bidirectional tristate line containing/ expecting parity bit of d(15:8) 28 a28 dp0 o i/o address bit 28 (intel non-parity/motorola) tristate when unused data parity 0 (intel parity mode), bidirectional tristate line containing/ expecting parity bit of d(7:0) 26, 21, 19, 15, 13, 8, 6, 2, 160, 156, 154, 149, 147, 143, 139, 135, 133, 128, 126, 122, 120, 116, 114, 109, 107, 102 a(27:2) o address bus tristate when unused. 91, 94, 96, 100 be(3:0) o byte enable (intel bus mode) the munich32 provides word and long word transfer. the byte enables determine the address offset to the address a31 ? a2, the actual word has been stored to. address offset size (motorola mode) indicates the number of bytes remaining to be transferred for this access. these signals define the active sections of the data bus. in both cases these signals are tristate when unused. see chapter 2.2 for details. pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 14 01.2000 38, 34, 32, 27, 25, 20, 18, 14, 12, 7, 5, 1, 159, 153, 148, 146, 142, 138, 134, 132, 127, 125, 121, 119, 115, 113, 108, 106, 101, 99, 95 d(31:0) i/o data bus the data bus lines are bidirectional tristate lines which interface with the system ? s data bus. 86 ds pchk o o data strobe (motorola mode) this signal indicates that valid data is to be placed on the data bus (read cycle) or has been placed on the data bus by the munich32 (write cycle). parity check (intel parity mode) this signal indicates, whether the parity bits of a read cycle are valid (pchk high) or invalid (pchk low). see chapter 2.2.1 for details. 84, 93, 89, 98, 105, 112, 118, 124, 129, 131, 137, 140, 145, 152, 158, 4, 11 , 17, 24, 31, 37, 57, 58, 63, 78 v dd i supply voltage 5 v 5% all pins must have the same level. 85 ads as o o address status (intel bus mode) this signal indicates that a valid bus cycle definition and address are being driven at the pins. address strobe (motorola bus mode) a valid address is transmitted on the address bus at the falling edge of as . in both cases this signal is active low and tristate when unused. pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 15 01.2000 90 w/r r/w o o write/read (intel bus mode) this signal distinguishes write from read operations. read/write (motorola bus mode) this signal distinguishes between read and write operations. in both cases this signal is tristate when unused. 75 ready dsack i i ready (intel bus mode) this signal indicates that the current bus cycle is complete. when ready is asserted during a read cycle the munich32 latches the input data and terminates the cycle. when ready is asserted during a write cycle the munich32 terminates the cycle. data transfer acknowledge (motorola bus mode) this active low input indicates that a data transfer may be performed. during a read cycle data becomes valid at the falling edge of dsack . the data is latched internally and the bus cycle is terminated. during a write cycle the falling edge of dsack marks the latching of data and the bus cycle is terminated. pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 16 01.2000 76 berr i bus error (intel and motorola bus mode) this active low signal informs the munich32 that a bus cycle error has occurred. the munich32 terminates the bus cycle. in case of an erroneous read cycle in the control and configuration section an ? action request fail ? interrupt is generated and the action is suspended. in case of an erroneous read cycle in the transmit data section the corresponding frame is aborted and a fo interrupt is generated. in all other cases of read or write cycles terminated with an error condition no further actions are performed by the munich32. please see chapter 2.2 , ? microprocessor interface ? , first paragraph and figure 18 . as bus cycles are executed without time limit this signal prevents a hang-up situation of the munich32. 74 b16 i word operation setting this bit to v dd causes the munich32 to perform 32-bit long word accesses to the shared memory, setting it to v ss causes the munich32 to perform 16-bit word accesses on the data lines d(15:0) only. in 16-bit word access mode the data lines d(31:16) should be left open. this bit is not dynamic and should be set to v dd in intel parity mode. pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 17 01.2000 82 hold br o i/o bus hold request (intel bus mode) this signal is driven high when the munich32 requests the control of the bus. bus request (motorola bus mode) this signal is driven low when the munich32 requests the control of the bus and is interpreted when another munich32 wants to be the bus master. 79 hlda bg i i bus hold acknowledge (intel bus mode) this active high signal indicates that the processor has released the control of the bus. the munich32 starts the bus cycles. bus grant (motorola bus mode) this active low signal indicates that the munich32 may assume the bus mastership. 81 bgack pm i/o i bus grant acknowledge (motorola bus mode) this signal is driven low by the device, when it has become the bus master. it also informs the munich32 whether another device is bus master. parity mode (intel bus mode) this signal has to be strapped to v dd before reset to enable the intel parity mode or to v ss before reset to enable the intel non-parity mode. it has to be left strapped during reset and operation. pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 18 01.2000 80 hldao bgo o o bus hold acknowledge passing on (intel bus mode) if another munich32 has initiated a hold request the hold acknowledge is passed on via hldao. the munich32 does not give another hold request before the hold acknowledge has been deactivated in order to prevent blocking in the case of continuous request by one munich32. bus grant acknowledge (motorola bus mode) if the munich32 has not requested the bus mastership it passes on the bus grant. the munich32 does not give another bus request before the bus request and the bus grant acknowledge have been deactivated in order to prevent blocking in the case of continuous request by one munich32. 66 ar i action request ar must be pulsed low to cause an action of the munich32. the ar is activated for updating the mode and channel configurations, setting a test loop, or initializing the interrupt queue. the min. time between reset and first ar is 500 s. pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 19 01.2000 40 int/int o interrupt request an interrupt is given when a transmission/ reception error is detected, frames are received or transmitted, or a host initiated action is performed. the interrupt pulse signal interacts with a write cycle to the shared memory. the data written into the interrupt queue contains the interrupt specification. the interrupt is active high for intel bus mode and active low for motorola bus mode. 44 rclk i receive clock this clock provides the data clock for rda t1/ds1 24-channel 1.544 mhz 24-channel 1.536 mhz cept 32-channel 2.048 mhz 32-channel 4.096 mhz 45 rsp i receive synchronization pulse this signal provides the reference for the receive pcm frame synchronization. it marks the first bit in the pcm frame. 46 rdata i receive data serial data is received at this pcm input port. the munich32 supports the t1/ ds1 24-channel pcm format, the cept 32-channel pcm format as well as a 32- channel pcm format with 4.096-mbit/s bit rate. 61 sclk i system clock pcm highway system clock highway frequency 32-channel 16.384 mhz 2.048 or 4.096 mhz 24-channel 12.288 mhz 1.536 mhz 24-channel 12.352 mhz 1.544 mhz pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 20 01.2000 51 ? 47 ci(4:0) i chip identification up to four munich32 can be connected to the pcm highway. these inputs define the start address of the control section pointer in the shared memory. ci4 is the polarity of a31 ? a22 ci3 is the polarity of a21 ? a16 ci2 is the polarity of a15 ? a4 ci1 is the polarity of a3 ci0 is the polarity of a2 a1, a0 are always ? 00 ? 56 ? 53 jtest (3:0) i/o test pins the munich32 supports the jtag boundary scan test and the jtag test standards. 65 test i test if this bit is set to v dd munich32 works in a test mode. for the functional working mode this bit must be set to v ss . 67 tdata o transmit data serial data is sent by this pcm output port is push-pull for active bits in the pcm frame and tristate for inactive bits. 68 tsp i transmit synchronization pulse this signal provides the reference for the transmit frame synchronization. it marks the last bit in the pcm frame. 69 tclk i transmit clock this clock provides the data clock for tdata t1/ds1 24-channel 1.544 mhz 24-channel 1.536 mhz cept 32-channel 2.048 mhz 32-channel 4.096 mhz pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 21 01.2000 60 reset i reset 41, 42, 43, 52, 70, 71, 72 n.c. - no connect these pins are reserved and should not be connected pin definitions and functions (cont ? d) pin no. p-mqfp-160-1 symbol input (i) output (o) function
peb 20320 introduction user ? s manual 22 01.2000 1.4 logic symbol figure 2 munich32 logic symbol itl03488 serial interface (3:0) be 1) a31/dp3, a30/dp2, a29/dp1, a28/dp0, a[27:2] (31:0) d 30 32 rclk rsp rdata tclk tsp tdata i/m w/r r/w ads/as ds/pchk ready/dsack berr b16 hold/br hlda/bg bgack/pm hldao/bgo ar int/int 5 (4:0) ci 4 test jtest (3:0) reset sclk v dd v ss interface system bus microprocessor interface munich32 peb 20320 1)
peb 20320 introduction user ? s manual 23 01.2000 1.5 functional block diagram figure 3 block diagram of munich32 itb03495 be (3:0) a (31:2) d (31:0) 32 rclk rsp rdata tclk tsp tdata i/m w/r ads ds ready/ berr b16 hold/ hlda/ hldao/ ar int/ ci (4:0) 4 test jtest reset bgack as dsack br r/w bg bgo int sclk 5 microprocessor bus interface serial interface/formatter controller unit csr configuration and state ram cm dma controller formatter transmit tf tb transmit buffer deformatter receive rd receive buffer rb cd mi / pm
peb 20320 introduction user ? s manual 24 01.2000 the internal functions of munich32 are partitioned into 8 major blocks. 1. serial interface, formatter control unit cd ? parallel-serial conversion, pcm timing, switching of the test loops, controlling of the multiplex procedure. 2. transmit formatter tf ? hdlc frame, bit stuffing, flag generation, flag stuffing and adjustment, crc generation, transparent mode transmission and v.110, x.30 80 bit framing. 3. transmit buffer tb ? buffer size of 64 long words allocated to the channels, i.e. eight pcm frames can be stored before transmission, individual channel capacity programmable. 4. receive deformatter rd ? hdlc frame, zero-bit deletion, flag detection, crc checking, transparent mode reception and v.110, x.30 80 bit framing. 5. receive buffer rb ? buffer size of 64 long words allocated to the channels, i.e. eight pcm frames can be stored, individual long words are freely accessible by each channel. 6. configuration and state ram csr ? since the transmit formatter, receive deformatter are used in a multiplex manner, the state and configuration information of each channel has to be stored. 7. dma controller cm ? interrupt processing, memory address calculation, chaining list handling, chip configuration. 8. p interface mi ? motorola/intel microprocessor interface.
peb 20320 introduction user ? s manual 25 01.2000 1.6 system integration the munich32 is designed to handle up to 32 data channels of a pcm highway. it transfers the data between the pcm highway and a memory shared with a host processor via a 32-bit p interface. at the same time it performs protocol formatting and deformatting as well as rate adaption for each channel independently. the host sets the operating mode, bit rate adaption method and time slot allocation of each channel by writing the information into the shared memory. using subchanneling each time slot can be shared between up to four munich32s; so that in one single time slot four different d-channels can be handled by four munich32s. figure 4, figure 5 and figure 6 give a general overview of system integration of the munich32. figure 4 general system integration (intel bus mode) its03489 munich32 0 hlda 1 munich32 hlda munich32 2 hlda 3 munich32 hlda cpu optional system bus up to 4 munich32 pcm highway (2.048 mbit/s, 1.544 mbit/s, 1.536 mbit/s, 4.096 mbit/s) cpu memory hold hlda hold hlda hldao hold hldao hlda hold hldao hlda hold hlda
peb 20320 introduction user ? s manual 26 01.2000 figure 5 general system interface (intel bus mode) figure 6 general system interface (motorola bus mode) its03490 munich32 munich32 memory cpu system bus pcm highway (2.048 mbit/s, 1.544 mbit/s, 1.536 mbit/s, 4.096 mbit/s) hold hlda hold hlda hldao its03491 munich32 munich32 cpu optional system bus up to 4 munich32 pcm highway cpu memory br bg bgack bgack bg br
peb 20320 introduction user ? s manual 27 01.2000 munich32 ? s bus interface consists of a 32 bit bidirectional data bus (d31 ? d0), 32/28 address lines (a31 ? a2, be3 ? be0) or (a27 ? a2, be3 ? be0), four data byte parity lines dp(3:0), five lines (w/r /r/w , ads /as , ds /pchk , berr ready /dsack ) to control and monitor the bus cycle, one action request and one interrupt line. the system bus allocation is controlled by the four signals (hold/br , hlda/bg , bgack , hldao/bgo ). a mode pin allows the bus interface to be configured for either intel or motorola mode. an operation mode pin b16 enables the transfer of a 32 bit long word in two consecutive 16 bit word operations. figure 7, figure 8, figure 9 , figure 10 and figure 11 illustrate how the munich32 may be used in different applications, like in a primary rate interface, a router, a packet switch and a central d-channel handler, as part of an isdn switching system. figure 7 architecture of a primary access board its07372 host interface (alternative b) system bus local cpu bus cpu (alternative a) int/int ar pcm system interface cpu bus arbitration 2254 falc54 peb controller interrupt memory system system bus controller interface line t1/s2 line 20320 munich32 peb host interface
peb 20320 introduction user ? s manual 28 01.2000 figure 8 architecture of a central d-channel handler its04829 epic peb 2056 interrupt controller hscx sab 82525 system bus controller system bus cpu peb 20320 munich32 int/int ar pcm system interface local cpu bus cpu bus arbitration memory system signaling highway pcm highway (alternative b) host interface (alternative a) r host interface
peb 20320 introduction user ? s manual 29 01.2000 figure 9 architecture of a packet switch/router its07374 controller system bus system bus cpu int/int ar pcm system interface local cpu bus cpu bus arbitration memory line driver v.24, v.21, v.35, ... 2254 falc54 peb interrupt system controller interface line t1/s2 line 20320 munich32 peb sab 82538 escc8
peb 20320 introduction user ? s manual 30 01.2000 figure 10 munich32 in a system with a risc cpu note: to reduce complexity the host interface is not explicitly shown here. its07371 interrupt controller system memory system bus controller system bus cpu motorola 68020) with intel 386 or (not compatible int/int ar pcm system interface line interface t1/s2 line local cpu bus local cpu bus cpu bus arbitration cpu bus arbitration falc54 peb 2254 munich32 20320 peb
peb 20320 introduction user ? s manual 31 01.2000 figure 11 munich32 in a system using multiport memory note: to reduce complexity the host interface is not explicitly shown here. its07373 system bus controller multi port ram cpu int/int ar local cpu bus local cpu bus cpu bus arbitration cpu bus arbitration system bus memory multi port 20320 munich32 peb 2254 falc54 peb controller interrupt memory system controller interface line t1/s2 line interface system pcm
peb 20320 functional description user ? s manual 32 01.2000 2 functional description 2.1 serial interface the serial interface of munich32 includes a data receive (rdata) and a data transmit line (tdata) as well as the accompanying control signals (rclk = receive clock, rsp = receive synchronization pulse, tclk = transmit clock, tsp = transmit synchronization pulse). the timings of the receive and transmit pcm highway are independent of each other, i.e. the frame positions and clock phases are not correlated. data is transmitted and received either at a rate of 2.048 mbit/s for the cept 32-channel european pcm format ( figure 14 ) or 1.544 mbit/s or 1.536 mbit/s for the t1/ds1 24-channel american pcm format ( figure 12 and figure 13 ). munich32 may also be connected to a 4.096-mbit/s pcm system ( figure 15 ), where it handles either the even- or odd-numbered time slots, so all 64 time slots can be covered by connecting two munich32s to the pcm highway. the actual bit rate of a time slot can be varied from 64 kbit/s down to 8 kbit/s for the receive and transmit direction. a fill mask code specified in the time slot assignment determines the bit rate and which bits of a time slot should be ignored. any of these time slots can be combined to a data channel allowing transmission rates from 8 kbit/s up to 2.048 mbit/s. the frame alignment is established by the transmit and receive synchronization pulse (tsp, rsp), respectively. the sampled rising edge of tsp identifies the current bit on the serial line (tdata) as the last bit of a pcm frame. the sampled rising edge of rsp indicates that the current bit on the serial line (rdata) is the first bit of a pcm frame. the f-bit for the 1.544 mhz t1/ds1 24-channel pcm format is ignored in receive direction, the corresponding bit is tristate in transmit direction. it is therefore assumed that this channel is handled by a different device. for test purposes four different test loops can be switched. in a complete loop all logical channels are mirrored either from serial data output to input (internal loop) or vice versa (external loop). in a channelwise loop one single logical channel is logically mirrored either from serial data output to input (internal loop) or vice versa (external loop). a detailed description of the different loops is found in chapter 4.2.1 and chapter 5.1.
peb 20320 functional description user ? s manual 33 01.2000 figure 12 t1/ds1 mode pcm frame timing 1.544 mhz note 1: a box in a bit of the rdata line means that this bit is ignored (hdlc, tmb, tmr, v.110/x.30) or received as ?1?-bit (tma; one overwrite). note 2: the fill/mask bit for the f-bit is not defined. tdata is tristate for the f-bit, and the f-bit is ignored in the receive direction. note 3: tsp and rsp must have one single rising and falling edge during a 125 s pcm frame. itd03496 t1/ds1 - mode receive frame timing 1 1 0 1 0 1 1 0 fill/mask : slot 0 fill/mask : slot 0 1 0 0 1 1 0 0 0 t1/ds1 - mode transmit frame timing tclk tsp tdata fill/mask 0 slot 23 slot 1 slot 0 125 s pcm - frame slot 0 slot 1 slot 23 12 3 4 5 6 7 0 12 3 4 5 6 7 f 7 f 0 12 3 4 5 6 7 7 6 5 4 3 2 1 0 f 7 slot 23 slot 1 slot 0 fill/mask rdata rsp rclk data data data data data data 6 6
peb 20320 functional description user ? s manual 34 01.2000 figure 13 t1/ds1 mode pcm frame timing 1.536 mhz note 1: a box in a bit of the rdata line means that this bit is ignored (hdlc, tmb, tmr, v.110/x.30) or received as ? 1 ? -bit (tma; one overwrite). note 2: tsp and rsp must have one single rising and falling edge during a 125 s pcm frame. itd03497 t1/ds1 - mode receive frame timing 1 1 0 1 0 1 1 0 fill/mask : slot 0 fill/mask : slot 0 1 0 0 1 1 0 0 0 t1/ds1 - mode transmit frame timing tclk tsp tdata fill/mask 0 slot 23 slot 1 slot 0 125 s pcm - frame slot 0 slot 1 slot 23 12 3 4 5 6 7 0 12 3 4 5 6 7 7 0 12 3 4 5 6 7 slot 23 fill/mask rdata rsp rclk data data data data data data 6 6 7 6 5 4 3 2 1 0 7 slot 1 slot 0
peb 20320 functional description user ? s manual 35 01.2000 figure 14 cept mode pcm frame timing note 1: a box in a bit of the rdata line means that this bit is ignored (hdlc, tmb, tmr, v.110/x.30) or received as ? 1 ? -bit (tma; one overwrite). note 2: tsp and rsp must have one single rising and falling edge during a 125 s pcm frame. itd03498 cept - mode pcm - frame timing 1 1 0 1 0 1 1 0 fill/mask : slot 0 fill/mask : slot 0 1 0 0 1 1 0 0 0 cept - mode transmit frame timing tclk tsp tdata fill/mask 0 slot 31 slot 1 slot 0 125 s pcm - frame slot 0 slot 1 slot 31 12 3 4 5 6 7 0 12 3 4 5 6 7 7 0 12 3 4 5 6 7 slot 31 fill/mask rdata rsp rclk data 6 6 7 6 5 4 3 2 1 0 7 slot 1 slot 0 data data data data data data
peb 20320 functional description user ? s manual 36 01.2000 figure 15 4.096 mbit/s pcm frame timing note 1: a box in a bit of the rdata line means that this bit is ignored (hdlc, tmb, tmr, v.110/x.30) or received as ? 1 ? -bit (tma; one overwrite). note 2: tsp and rsp must have one single rising and falling edge during a 125 s pcm frame. itd03528 0 12 3 4 5 6 7 slot 0 slot 1 7 6 5 4 3 2 1 0 slot 31 7 6 5 4 3 2 1 0 125 s tsp rsp 4.096 mbit/s pcm-format: even numbered slot allocation 4.096 mbit/s pcm-format: odd numbered slot allocation rsp tsp 0 12 3 4 5 6 7 slot 31 0 12 3 4 5 6 7 slot 0 7 6
peb 20320 functional description user ? s manual 37 01.2000 figure 16 example: programmable channel allocation for 32 time slots figure 17 example: programmable channel allocation for 24 time slots itd03499 125 s 0 0 32 x 64 kbit/s 1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031 121 3 4 1 5 6 78791 itd03500 125 s 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 0 12 3 4 5 12 6 3 24 x 64 kbit/s
peb 20320 functional description user ? s manual 38 01.2000 2.2 microprocessor interface a 64-channel dma controller (32 channels in receive direction and 32 channels in transmit direction) with buffer chaining capability is integrated in the munich32. it provides dma functions for up to 32 full duplex channels and allows data transfer between the serial interface and an external memory. the munich32 performs long word by long word transfers on a 32-bit bidirectional data bus (d(31:0)) and addresses up to 4 gbyte of ram with a 30-bit address bus (a(31:2)). the chip always works as a system bus master and can be operated in either a intel or motorola environment. munich32 receives commands and data from the host processor via the shared memory. the host stores the action specification containing configuration initialization and monitor commands in the memory. afterwards the host informs the munich32 by generating an action request pulse (ar line). the munich32 reacts by reading the action specification and informs the microprocessor by appending the respective interrupt information to the interrupt queue. in addition, the int/int line is activated during the write access belonging to the interrupt specification. the timing of the microprocessor interface is established according to the intel 80386 or motorola 68020 processor. the system clock (sclk) provides the fundamental timing for the p interface and is the internal device clock. each bus cycle performs a long word (b16 = 1) or a word (b16 = 0) transfer and takes four system clock periods in the fastest case, any number of wait clock cycles can be inserted. munich32 ? s architecture is based on a 32-bit data structure. therefore munich32 performs long word operations preferably. while the word operation mode is selected the long word operation is divided into two consecutive word operations. in the case of a read access the data of the two words are connected together to build a 32-bit long word before processing. for a read access first the msb bytes of a long word will be transferred and then the lsb bytes via d(15:0). for a write access first the lsb-bytes of a long word will be transferred and then the msb bytes via d(15:0). the signal b16 cannot be changed dynamically and should be set to ? 1 ? in intel parity mode (parity mode is not available in 16-bit word intel mode). mode operation mode b16 be(3 ? 0) access intel motorola 1 0 0 1 0 0 0 h 3 h c h 0 h 8 h a h long word msb word lsb word long word msb word lsb word
peb 20320 functional description user ? s manual 39 01.2000 2.2.1 intel mode the intel mode has two submodes ? parity mode (even parity) and non parity mode ? to be chosen by strapping pm to ? 1 ? or ? 0 ? respectively. in intel mode the lower (higher) ordered byte of a long word (d31 ? d0) is assigned to the lower (higher) ordered physical address. the read or write bus cycle is controlled by the signals w/r , ads and ready as shown in figure 18, figure 19. each bus cycle consists of two bus states (s1, s2). during state s1 the address signals and bus cycle definition signals are driven valid. simultaneously, the address status ads is asserted to indicate their availability. the bus cycles are terminated by asserting ready . ready is ignored on the first bus state s1 and sampled at the end of the following state s2. if ready is not asserted in s2 then wait cycles sw are inserted until a bus cycle end is detected. during a read cycle the munich32 floats its data signals to allow external memory to drive the data bus. the input data and parity bits dp3 ? 0 (if parity mode is selected) is latched when ready is asserted. during a write cycle munich32 drives the data signals and parity bits dp3 ? 0 (if parity mode is selected) beginning in the second clock period of s1 until the first clock period following the cycle acknowledgment ready . if a bus cycle error indicated by berr has occurred, the munich32 terminates the bus cycle. in case of a read cycle in the control and configuration section an action request fail interrupt is generated and the action is suspended. in case of a read cycle in the transmit data section the corresponding frame is aborted and a fo interrupt is generated. in all other cases of read or write cycles terminated with an error condition no actions are performed. a 4-bit data byte parity bus dp3 ? 0 is used in intel mode if parity mode is selected by strapping pm to ? 1 ? . during a read access dp3 ? 0 is supposed to contain the parity of d(31:24), d(23:16), d(15:8) and d(7:0) respectively. a low active output pchk indicates whether the parity was correct (pchk = 1) or wrong (pchk = 0) in the clock cycle after the data/parity is latched. pchk stays low 1 or 2 clock cycles. no further action is taken as consequence to a parity fail. as the memory access is performed by using one common system bus, bus management is done with the signals hold, hlda and hldao as shown in figure 20 . the wired or hold line is driven high whenever one of the munich32s has to perform a bus transfer. the activated hold acknowledge indicates that the bus control will be released. if the specific device has activated the hold itself, it will start the memory access. otherwise it will pass the signal to the next cascaded device. several memory accesses may be required if the munich32 has not been granted access recently. in this example of four munich32 devices sharing the same bus, each device will generate four memory cycles, giving a total of 16 cycles per hold/hlda/hldao tenure. in order to prevent blocking in the case of continuous request by one device, the munich32 does not generate another hold request before the hold acknowledge has been deactivated.
peb 20320 functional description user ? s manual 40 01.2000 if the hold acknowledge is driven low while the munich32 is performing a bus cycle, the bus is released later than two clock periods after de-assertion of hold acknowledge. the current bus cycle is finished with a bus cycle error. this action should be followed by an asp.res as described in chapter 4.2.1 . figure 18 read cycle timing diagram (intel mode) itd03501 s1 s2 s1 s2 s1 s2 s ww s read read berr sclk be(3:0) w/r ads ready [dp3-dp0], d(31:0) berr tristate a31-a2 [a27-a2] [pchk]
peb 20320 functional description user ? s manual 41 01.2000 figure 19 write cycle timing diagram (intel mode) itd03502 write write berr sclk be(3:0) w/r ads ready [dp3-dp0], d(31:0) berr tristate a31-a2 [a27-a2] int [pchk]
peb 20320 functional description user ? s manual 42 01.2000 figure 20 bus management for intel bus mode note 1: bus cycle means, that the munich32 under consideration starts a read or write access at most 4 clock periods after hlda is asserted after its hold. the munich32 terminates the cycle typically two clock periods after the last bus cycle. note 2: in the bus management example it is assumed that the munich32 under consideration has a higher priority than the other bus master. hold (internal) is therefore the internal request generated by the munich32, hold (external) the signal on the external hold line, being the or combination of the hold signal generated by the munich32 and the other bus master(s). note 3: a typical configuration example for a system with several bus masters is given in figure 4 and figure 5 . itd03503 sclk hold (extern) hold (intern) hlda hldao bus cycle max. 4 clock periods ~ ~ ~ ~ munich32 gets the bus gets the bus another bus master requests no bus tristate tristate tristate tristate
peb 20320 functional description user ? s manual 43 01.2000 2.2.2 motorola mode in motorola mode the bus is used in an asynchronous manner. the bus operation uses the handshake lines (as , ds , dsack and berr ) to control data transfer as shown in figure 21, figure 22 . address strobe as indicates the validity of an address on the address bus (a31 ? a2) and of the bus definition r/w (read or write cycle). it is asserted half a clock cycle after the beginning of a bus cycle. the data strobe ds signal is used as a condition for valid data of a write cycle. munich32 asserts ds one full clock cycle after the assertion of as during a write cycle. the data is placed on the bidirectional data bus (d31 ? d0) half a clock cycle after as is driven low. for a read cycle, munich32 asserts ds to signal the external memory to drive the data on the bus. ds is asserted at the same time as as during a read cycle. the data is latched with the last falling edge of the clock for that cycle. the bus cycle is terminated if the data transfer acknowledge (dsack ) is asserted with the falling edge of the third clock period. otherwise munich32 inserts wait cycles until dsack is recognized. as and ds are driven high half a clock period before bus cycle end. the bus error berr is also a bus cycle termination indicator. it can be used in the absence as well as in conjunction with dsack . if an abnormal termination has occurred during a read cycle, munich32 generates an interrupt and aborts the corresponding transmit channel. for a write cycle no further action is performed. as the munich32 is used in a multi-bus-master application, bus arbitration has to be done to avoid simultaneous system bus access by more than one master. in motorola mode the bus arbitration protocol of the 68020 is established using the signals br , bg , bgack and bgo as shown in figure 23 . the wired-or bus request (br ) is driven low to indicate to the processor that one of the munich32s requires control of the bus. the activated bus grant (bg ) signals the availability of the system bus. if the munich32 has activated the bus request itself, it asserts the wired-or bus grant acknowledge to indicate that it has assumed bus mastership. otherwise it will pass the bus grant signal to the device cascaded next (bgo ). at the same time it releases the bus request. after finishing the last bus cycle, the bus grant acknowledge is deactivated and the bus grant is passed on. in order to prevent blocking in the case of continuous request by one device, munich32 does not generate another bus request before the external bus request and bus grant acknowledge have been deactivated. after getting the bus mastership munich32 drives the bus and starts the first bus cycle one clock after assertion of bgack . after finishing the memory access it releases the bus and de-asserts bgack at the same time.
peb 20320 functional description user ? s manual 44 01.2000 figure 21 read bus cycle timing diagram for motorola bus mode figure 22 write bus cycle timing diagram for motorola bus mode itd03504 read read berr sclk a31-a2, be (3:0) r/w as dsack d (31:0) berr tristate ds itd03505 write write berr sclk a31-a2, be (3:0) r/w as dsack d (31:0) berr tristate ds int
peb 20320 functional description user ? s manual 45 01.2000 figure 23 bus management for motorola mode note: 1. in the bus management example it is assumed that the munich32 under consideration has a higher priority than the other bus master. br and bgack are wired and lines to be pulled to ? 1 ? by an external signal. 2. a typical configuration example for a system with several bus masters is given in figure 6 . itd03506 sclk br (extern) br (intern) bgack (extern) bgack (intern) bgo bg max. 4 clock periods ~ ~ ~ ~ munich32 gets the bus gets the bus another bus master no bus requests
peb 20320 functional description user ? s manual 46 01.2000 2.2.3 dma priorities prioritization of queueing dma cycles the munich32 will perform all pending accesses on the same bus tenure. note: several bus transactions may be required if the munich32 has not been given access to the system bus for a long period of time. this is often seen in multi- master systems where several munich32 devices share the system bus. priority interrupt highest priority receive link list including accesses to the descriptors transmit link list including accesses to the descriptors lowest priority configuration of a channel (action requests)
peb 20320 functional description user ? s manual 47 01.2000 2.3 basic functional principles munich32 is a multichannel network interface controller for hdlc, offering a variety of additional features like subchanneling, data channels comprising of one or more time slots, dmi 0, 1, 2 transparent or v.110/x.30 transmission and programmable rate adaption. munich32 performs formatting and deformatting operations in any network configuration, where it implements, together with a microprocessor and a shared memory, the bit oriented part (flag, bit stuffing, crc check) of the layer 2 (data link protocol level) functions of the osi reference model. the block diagram is shown in figure 3 . munich32 is designed to handle up to 32 data channels of a 1.536/1.544 mbit/s t1/ds1 24-channel, 2.048-mbit/s cept 32-channel or a 4.096-mbit/s 32-channel pcm highway. the device provides transmission for all bit rates from 8 kbit/s up to 2.048 mbit/s of packed data in hdlc format or of data in a transparent format supporting the dmi mode (0, 1, 2) or v.110/x.30 mode. tristating of the transmission line as well as switching a channelwise or complete loop are also possible. an on-chip 64-channel dma generator controls the exchange of data and channel control information between the munich32 and the external memory. the munich32 processes receive and transmit data independently for each time slot and transmission direction respectively (blocks tf = transmit formatter, rd = receive deformatter). the frame counters are reset by the rising edges of the rsp or tsp line. the processing units tf and rd work with a multiplex management, i.e. there exists only one protocol handler, which is used by all channels in a time sharing manner (see figure 24 and figure 25 ). the actual configuration, e.g. transmission mode, channel assignment, fill/mask code or state of the protocol handlers is retrieved from the configuration and state ram (csr) at the beginning of the time slot and reloaded to the csr at the end. the control unit (cd) controls the access to the csr and allows writing of reconfiguration information only if the continuous transfer of the configuration information between the csr and the formatters (tf and rd) will not be disturbed. in receive direction, 32 unpacked data bits are first accumulated and then stored into an on-chip receive buffer (rb) for transfer to the shared memory. as soon as the rb receives 32 bits for a channel it requests access to the parallel microprocessor bus. the on-chip transmit buffer (tb) is always kept full of data ready for transmission. the tb will request more data when 32 bits become available in the itbs. these buffers allows a flexible access to the shared memory in order to prevent data underflow (tx) and data overflow (rc). the transmit buffer (tb) has a size of 64 long words (= 256 bytes). in this buffer, data of 8 pcm frames can be stored for each data channel. in this case, there are max. 1 ms between access to the shared memory and data supply to the transmit formatter. in order to meet these requirements a variable and programmable part of the buffer (itbs) must be allocated to each data channel (see figure 26 ).
peb 20320 functional description user ? s manual 48 01.2000 figure 24 multiplex management receive direction rdata bit 0 1 bit 2 bit sclk active rclk (external) channel receive 1 x channel active receive 0 x (internal) 2 x for into rd load cd, csr data x 1 phase of rd, cm protocol operation bit 7 bit ~ ~ ~ ~ 0 1 bit for into rd load csr data ~ ~ ~ ~ ~ ~ ~ ~ 1 x no operation of rd, wait phase reload rd into csr x 3 2 x 2 x operation disabled rd protocol data into csr channel config might write new rdata csr cd rd csr 1 x ... cm rd csr x operation disabled rd protocol cm might write new channel config data into csr csr protocol operation disabled fifo cm csr x 1 rd rdata cd 2 rd itd04397
peb 20320 functional description user ? s manual 49 01.2000 figure 25 multiplex management transmit direction itd04398 tdata tclk active transmit channel (external) sclk active transmit channel (internal) x x load csr data tf protocol operation disabled protocol operation phase of tf, cm might write new channel config data into csr data into csr channel config cm might write new no operation of tf wait phase operation disabled tf protocol into csr, cd reload tf x x x bit 7 0 bit bit 1 bit 6 bit 7 0 bit csr csr tf cm x ... csr cm fifo csr cd tf tdata ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 0 12 0 1 1 x 2 x 0 x 1 x 1 for into tf x 1 tf
peb 20320 functional description user ? s manual 50 01.2000 for example: a) 2.048-mbit/s pcm highway 32 64-kbit/s data channels (8 bits are sent with each pcm frame). two long words of the buffer are allocated to each data channel. b) 1 2.048-kbit/s data channel the maximum buffer size for one channel (63 long words) is allocated to this data channel. c) 6 256-kbit/s and 8 64 kbit/s data channels. eight long words of the buffer are allocated to each of the 6 data channels with 256 kbit/s and two long words are assigned to each of the 8 data channels with a transmission rate of 64 kbit/s. the choice of the individual buffer size of each data channel can be made in the channel specification (shared memory). the buffer size of one channel is changeable without disturbing the transmission of the other channels. figure 26 partitioning of tb itd04396 cd tf unused tb active transmit channel (internal) used as address offset for tb itbs of channel x 1 64 long words 0 x x 3 2 x itbs of channel itbs of channel itbs of channel
peb 20320 functional description user ? s manual 51 01.2000 the receive buffer (rb) is a fifo buffer and also has a size of 64 long words, which allows storing the data of eight complete pcm frames before transferring to the shared memory. figure 27 partitioning of rb the data transfer to the shared memory is performed via a 32-bit microprocessor interface working either in siemens/intel or motorola bus mode. figure 28 shows the division of the shared memory required for each munich32: ? configuration start address located at a programmable address ? control and configuration section ? an interrupt circular queue with variable size ? descriptor and data sections for each channel. itd04447 64 long words active receive channel (internal) stored in rb together with data/status word from rd cd rd rb
peb 20320 functional description user ? s manual 52 01.2000 figure 28 memory division for up to four munich32 interrupt queue receive descriptor data receive receive data descriptor receive descriptor receive channel 31 spec. channel 0 spec. time-slot assignment interrupt queue spec. action spec. transmit descriptor data transmit transmit data descriptor transmit transmit descriptor control start address ci(4:0) control and configuration section section configuration control and ci(4:0) descriptor transmit transmit descriptor data transmit transmit data descriptor transmit action spec. interrupt queue spec. time-slot assignment channel 0 spec. channel 31 spec. receive descriptor receive descriptor data receive receive data descriptor receive queue interrupt interrupt queue receive descriptor data receive receive data descriptor receive descriptor receive channel 31 spec. channel 0 spec. time-slot assignment interrupt queue spec. action spec. transmit descriptor data transmit transmit data descriptor transmit transmit descriptor ci(4:0) control and configuration section section configuration control and ci(4:0) descriptor transmit transmit descriptor data transmit transmit data descriptor transmit action spec. interrupt queue spec. time-slot assignment channel 0 spec. channel 31 spec. receive descriptor receive descriptor data receive receive data descriptor receive queue interrupt itd03507 control start address control start address control start address current receive descriptor address 0 ... 31 current transmit descriptor address 31 ... 0 0 ... 31 current transmit descriptor address 31 ... 0 current receive descriptor address current receive descriptor address 0 ... 31 current transmit descriptor address 31 ... 0 current receive descriptor address 0 ... 31 current transmit descriptor address 31 ... 0
peb 20320 functional description user ? s manual 53 01.2000 the shared memory allocated for each transmit and receive channel is organized as a chaining list of buffers set up by the host. each chaining list is composed of descriptors and data sections. the descriptor contains the pointer to the next descriptor, the start address and the size of a data section. it also includes control information like frame end indication, transmission hold and rate adaption with interframe time-fill. in the transmit direction the munich32 reads a transmit descriptor, calculates the data address, writes the current transmit descriptor address into the ccs, and fills the on-chip transmit buffer. when the data transfer of the specified section is completed, the munich32 releases the buffer, and branches to the next transmit descriptor. if a frame end is indicated the hdlc, tmb or tmr frame will be terminated and a specified number of the interframe time-fill byte will be sent in order to perform rate adaption. if frame end is found in a transmit descriptor tma channel the specified number of programmable tma flags is appended to the data in the descriptor. if frame end is found in a transmit descriptor of a v.110/x.30 channel the frame is aborted (after the data in the descriptor are sent) by finishing the current 10-octet frame with ? zeros ? and sending 2 more 10-octet frames with ? zeros ? which leads to a loss of synchronism on the peer side. an adjustment for the inserted zeros in hdlc is programmable, which leads to a reduction of the specified number of interframe time-fill by 1 / 8 th of the number of zero insertions. this can be used to send long hdlc frames with a more or less fixed data rate in spite of the zero insertions. a maskable interrupt is generated before transmission is started again.
peb 20320 functional description user ? s manual 54 01.2000 the following sections give examples of typical transmit situations for the individual modes variable size frame oriented protocols (hdlc, tmb, tmr) normal operation, handling of frame end (fe) indication and hold (h) indication. note: 1. fnum0 must be set to zero. 2. flag = 7e h for hdlc 00 h for tmb, tmr ic = 7e h for hdlc and iftf = 0 ff h for hdlc and iftf = 1 00 h for tmb, tmr 3. after sending the fnum2 ? 1 ic characters the device starts polling the hold bit in the transmit descriptor once for each further sent ic character. it also rereads the pointer to the next transmit descriptor once with each poll of the hold indication. the pointer to the next transmit descriptor can be changed while hold = 1 is set. the value of the pointer, (read in the poll where hold = 0) is used as the next descriptor address. if more than 6 ic characters will be sent, the use of the transmit hold (th) should be considered as an alternative to using the descriptor hold bit. see chapter 5.3.2 .
peb 20320 functional description user ? s manual 55 01.2000 figure 29 itd04446 fe= 0 h=0 0 = h 1 = fe fe =1 h=1 flag data 4 .... . . . data 1 data 2 data 3 transmit descriptors data sections ... fnum1+1 3 data poll h=1? poll h=0 next transmit descr. descr. transmit next descr. transmit next fnum0 fnum1 fnum2 data 4 (data 1, data 2) flag, fnum2 ... flag c, , c ... frame ( frame ) frame () ... c , c flag, c , flag c, , c c ... ,
peb 20320 functional description user ? s manual 56 01.2000 fixed size frame oriented protocols (v110/x.30) normal operation, e, s, x change (indicated by the v.110-bit in the transmit descriptor) example for trv = ? 11 ? note: 1. fnum must be 0 for all transmit descriptors. 2. the actual e-, s-, x-bits have to be in the first transmit descriptor after reset. 3. as shown in the example the contiguous parts of a data section belonging to one descriptor are sent in contiguous frames (data 1 (1) are the bytes 0 ? 3 of data 1, data 1 (2) are the bytes 4 ? 7 of data 1). if the end of a data section is reached within a frame, the frame is continued with data from the next data section belonging to a transmit descriptor with the bit v.110 = 0 (data 2 (2) = byte 4 of data 2, data 3 (1) =byte 0 ? 2 of data 3). 4. the e-, s-, x-bits are only changed from one frame to the next not within a frame. the change occurs in the first frame which does not contain data of the previous data section. 5. neither fe nor h may be set to 1 during a normal operation of the mode. they both lead to an abort of the serial interface.
peb 20320 functional description user ? s manual 57 01.2000 figure 30 itd04444 next transmit descr. no=2 v110=1 fe=0 h =0 0 = 0 = h 0 = fe v110 no= 8 5 = no v110 fe= 0 h=0 =0 1 = 0 = h 0 = fe v110 no= 2 0 = 0 = h 0 = fe v110 no= 9 frame ( e, s, x, data 1 ) (1) (2) (1) (2) (1) (2) ..... . .. 10 octets 10 octets 10 octets 10 octets 10 octets e, s, x, data 1 e , s , x , transmit descriptors data sections ...00 descr. transmit next descr. transmit next descr. transmit next descr. transmit next frame ( e, s, x, data 1 ) frame ( e, s, x, data 2 ) frame ( e, s, x, data 2, data 3 ) frame ( e , s , x , data 3 ) data 2 data 3
peb 20320 functional description user ? s manual 58 01.2000 fixed size frame oriented protocols (v.110/x.30) handling of frame end (fe) indication note: 1. fnum must be ? 0 ? for all transmit descriptors. 2. the frame (e, s, x, data 2 (2) ) is the beginning of a 10-octet frame. it stops with the octet no. y, containing the last data bit of data 2 to be sent. 3. since y = 1, , 10 the 20 + y times 00 h characters sent afterwards cause the peer station to recognize 3 consecutive 10-octet frames with frame error which leads to a loss of synchronism in the peer station. 4. for y = 10 data 2 is identical to data 2 (1) and 30 times 00 h characters are sent after frame (e, s, x, data 1 (2) , data 2 (1) ). 5. the e-, s-, x-bits are supposed to be loaded by an earlier transmit descriptor in the example. a descriptor changing them (with v.110-bit set) can be put between, before or after the descriptors in the example. it will change these bits according to the rules discussed previously.
peb 20320 functional description user ? s manual 59 01.2000 figure 31 itd04448 v110 fe= 0 h=0 =0 0 = 0 = h 1 = fe v110 v110 fe= 0 h=0 =0 frame ( (1) ) frame ( (2) ) 00,......,00 2 data data 3 ) (1) ( frame .... . . . 10 octets 10-y octets 20+y octets 10 octets data 1 data 2 data 3 transmit descriptors data sections ... e, s, x, 10 octets , x, s, e, (1) 2 data data 1 frame ( (2) ) y=1,...,10 1 data e, s, x, e, s, x,
peb 20320 functional description user ? s manual 60 01.2000 fixed size frame oriented protocols (v110/x.30) handling of hold (h) indication figure 32 itd04449 v110 fe= 0 h=0 =0 0 = 1 = h 1 = fe v110 v110 fe= 0 h=0 =0 frame ( (1) ) frame ( (2) ) 00,......,00 2 data data 3 ) (1) ( frame .... . . . 10 octets 10-y octets 20+y octets 10 octets data 1 data 2 data 3 transmit descriptors data sections ... e, s, x, 10 octets , x, s, e, (1) 2 data data 1 frame ( (2) ) y=1,...,10 00 00 ... 00 00 poll h=1? poll h=0 e, s, x, 1 data e, s, x,
peb 20320 functional description user ? s manual 61 01.2000 time slot oriented protocol (tma) normal operation, handling of frame end (fe) indication and hold (h) indication. note: 1. fnum must be set to zero. 2. tc = ff h for tma and fa = 0 the programmed flag with tma and fa = 1 3. after sending the fnum2 ? 1 ic characters the device starts polling the hold bit in the transmit descriptor once for each further sent ic character. it also rereads the pointer to the next transmit descriptor once with each poll of the hold indication. the pointer to the next transmit descriptor can be changed while hold = 1 is set. the value of the pointer, (read in the poll where hold = 0) is used as the next descriptor address. if more than 6 ic characters will be sent, the use of the transmit hold (th) should be considered as an alternative to using the descriptor hold bit. see chapter 5.3.2 .
peb 20320 functional description user ? s manual 62 01.2000 figure 33 itd04445 fe= 0 h=0 0 = h 1 = fe fe= 1 h=1 tc data 4 .... . . . data 1 data 2 data 3 transmit descriptors data sections ... fnum1+1 data 3 tc, tc, tc,........tc, tc poll h=1? poll h=0 next transmit descr. descr. transmit next descr. transmit next fnum0 fnum1 fnum2 data 4 data 1 data 2 time-slot boundaries tc,..................,tc tc, tc,.............tc, fnum2 ... ... . . . . . . . . .. ..
peb 20320 functional description user ? s manual 63 01.2000 an activated transmission hold (hold bit in descriptor) prevents the munich32 from sending more data. if a frame end has not occurred just before, the current frame will be aborted and an interrupt generated. afterwards, the interframe time-fill bytes will be issued until the transmission hold indication is cleared. there is a further transmit hold (th) bit in the channel specification (ccs) in addition to the hold bit in the descriptor. setting the transmit hold (th) bit by issuing a channel command will prevent further polling of the transmit descriptor (see chapter 5.3.2 ). this hold bit (ccs.th) is interpreted in the cd; it causes the transmit formatter to stay in the idle state and to send interframe time-fill after finishing the current frame. in the case of a very short frame (< itbs), this frame will stay in the tf and not be sent until ccs.th is removed. (in case of x.30/v.110 the current frame is aborted). this means that the buffer tb is not emptied from the tf side after the current frame, but still requests further data from the shared memory until it is filled. in the case of the descriptor hold on the other hand, the tf empties the tb and there are no further data requests from the shared memory until the descriptor hold is withdrawn. then tb is filled again and the tf is activated only after enough data are provided in the tb to prevent a data underrun. the reaction to the transmit hold bit is now discussed for the different modes in the following sections variable size frame oriented protocols (hdlc, tmb, tmr) reaction to a channel specification containing th = 1 normal operation note: 1. ic = 7e h for hdlc and iftf = 1 ff h for hdlc and iftf = 0 00 h for tmb or tmr 2. flag = 7e h for hdlc 00 h for tmb or tmr 3. fnum2 is ignored. the number of interframe time-fills sent between the first frame and the second frame solely depends on the ar low pulse leading to the action with the channel with th = 0. 4. the times ? t 1 and ? t 2 are statistical but typically only a few clock cycles. 5. the th bit (as all channel commands) is not synchronized with tb! (as opposed to the h-bit in the descriptor) th acts on the frame currently being sent, not necessarily on the last frame currently stored in the tb. in the example, tb may or may not have stored data 3 before the action request with th = 1 was issued. see chapter 4.2.5 for a further discussion of this issue. 6. if th is handed over to cd outside of a frame, th = 1 prevents the munich32 from sending the next frame.
peb 20320 functional description user ? s manual 64 01.2000 figure 34 itd04450 fe= 0 h= 0 flag data 3 .... . . . data 1 data 2 ... ..., 1 data flag, c, () frame frame () c , flag ? t 1 ? t 2 th=1 th=0 in the channel specification handed over from cm to cd handed over from cm to cd in the channel specification ar . . . . .... , data 2 data 3 fnum2 0 = h 1 = fe
peb 20320 functional description user ? s manual 65 01.2000 fixed size frame oriented protocol (v.110/x.30) reaction to a channel specification containing th = 1 normal operation note: 1. the times ? t 1 and ? t 2 are statistical but typically only a few clock cycles. 2. the current frame processed, when th = 1 is handed over to cd is aborted, only 10 ? y, (y = 1, ? , 10) octets of it are sent. the device then starts to send 20 + y 00 h characters no matter how fast the th bit is withdrawn. this ensures, that the peer site is informed about the abort with a loss of synchronism 3. the data section data 1 is split in the example; data 1 (1) is sent in the aborted frame, all bits that were read into the munich32 with the same access are discarded (they would have been sent in the next frame(s) if th = 1 was not issued) and the device starts the next frame with the bits data 1 (3) of the access to data 1 that follows the one getting the bits of data 1 (1) . 4. the th (as all channel commands) is not synchronized with tb. th acts on the frame currently sent, not necessarily on the last stored data. 5. if th is handed over to cd before a frame has started after an abort or after reset no frame will start.
peb 20320 functional description user ? s manual 66 01.2000 figure 35 time slot oriented protocol (tma) reaction to a channel specification containing th = 1 note: 1. tc is the programmed tflag for fa = 1 ff h for fa = 0 2. the times ? t 1 and ? t 2 are statistical but typically only a few clock cycles. 3. the th bit (as all channel commands) is not synchronized with the tb! (as opposed to the h-bit in the descriptor) th acts to the data stream currently sent. itd04454 fe= 0 h= 0 .... . . . data 1 ... 10-y octets 1 data ... ? t 1 th=1 in the channel ar frame () (1) 00 specificaton handed over from cm to cd 00 00 00 ... ........... channel in the th=0 2 t ? 10 octets 1 data frame () (3) 20+y octets ... from cm to cd handed over specificaton e, s, x, e, s, x,
peb 20320 functional description user ? s manual 67 01.2000 figure 36 itd04452 fe= 0 h= 0 data 3 .... . . . data 1 data 2 ... fnum0 1 data tc, , tc tc, tc, ? t 1 ? t 2 th=1 th=0 in the channel specification handed over from cm to cd handed over from cm to cd in the channel specification ar , . . . . data 2 , data 3 time-slot boundaries = = fe h 0 1
peb 20320 functional description user ? s manual 68 01.2000 variable size frame oriented modes (hdlc, tmb, tmr) reaction to a channel specification containing th = 1 silencing of poll cycles for hold. note: an ar pulse for an action specification leading to th = 1 should be issued after (itbs + 2) polls of the munich32, where itbs is the previously programmed number of long words in the tb reserved for this channel.
peb 20320 functional description user ? s manual 69 01.2000 figure 37 itd04451 fe= 1 h= 1 flag data 2 .... . . . data 1 data 2 ... fnum0 poll h=1? poll h=0 fnum0 ..., 1 data flag, ... c, , c ... () frame frame () c , flag c, , c c ... , , poll h=1? , c ... no poll . . . c , ? t 1 ? t 2 th=1 th=0 in the channel specification handed over from cm to cd handed over from cm to cd in the channel specification ar . . . . ....
peb 20320 functional description user ? s manual 70 01.2000 fixed size frame oriented protocol (v110/.30) silencing of poll cycles by th = 1 note: 1. the times ? t 1 and ? t 2 are statistical but typically only a few clock cycles. 2. the th bit (as all channel commands) is not synchronized with tb! (as opposed to the h-bit in the descriptor) th acts to the data stream currently sent. 3. in the example the proper use to silence a channel polling the hold bit of the transmit descriptor is illustrated. the ar pulse is issued after the polling has started and the h-bit is not reset before polling has stopped by the th bit. 4. an ar pulse for an action specification leading to th = 1 should be issued after (itbs + 2) polls of the munich32, where itbs is previously programmed number of long words in the tb reserved for this channel.
peb 20320 functional description user ? s manual 71 01.2000 figure 38 itd04455 fe= 1 h= 1 .... . . . data 1 data 2 ... 10 octets 1 data ... poll h=1 ? t 1 th=1 in the channel ar frame () (1) (2) ) ( frame data 1 10-y octets 00 specif. handed over to cd h=1 no poll h=1 h=0 poll 00 00 00 ... ........... from cm to cd handed over specif. channel in the th=0 2 t ? 10 octets 2 data frame () (1) 20+y octets e, s, x, e, s, x, e, s, x,
peb 20320 functional description user ? s manual 72 01.2000 time slot oriented protocol (tma) reaction to a channel specification containing th = 1 note: 1. tc = ff h for tma and fa = 0 the programmed flag for tma and fa = 1 2. fnum2 is ignored. the number of interframe time-fills between the first frame and the second frame solely depends on the ar low pulse leading to the action with the channel with th = 0. 3. the times ? t 1 and ? t 2 are statistical but typically only a few clock cycles. 4. the th bit (as all channel commands) is not synchronized with tb (as opposed to the h-bit in the descriptor) th acts on the data stream currently sent not necessarily on the last data stored in tb. in the example tb may or may not have stored data 3 before action request with th = 1 was issued. 5. the data stream is stopped and tc sent after the last byte of data 2 is sent. the stopping is triggered by the fe = 1 bit in the descriptor. 6. if th is bonded over to cd during interframe time-fill (tc) it prevents the munich32 from sending further data afterwards. 7. an ar pulse for an action specification leading to th = 1 should be issued after (itbs + 2) polls of the munich32, where itbs is previously programmed number of long words in the tb reserved for this channel.
peb 20320 functional description user ? s manual 73 01.2000 figure 39 itd04453 fe= 1 h= 1 data 2 .... . . . data 1 data 2 ... fnum0 poll h=1? poll h=0 fnum0 ... 1 data ... tc, , tc ... tc, tc, , tc tc ... , , poll h=1? , tc ... no poll . . . tc, ? t 1 ? t 2 th=1 th=0 in the channel specification handed over from cm to cd handed over from cm to cd in the channel specification ar ,, tc . . . . ....
peb 20320 functional description user ? s manual 74 01.2000 in receive direction the munich32 reads a receive descriptor, calculates the data address, writes the current receive descriptor address into the ccs, and exchanges data between the on-chip receive buffer and the external memory. after the data section has been filled, the munich32 writes the number of stored bytes (bno) into the descriptor. if a frame end has occurred the frame status is written into the descriptor and an interrupt is generated. the frame status includes the crc check results and transmission error information like ? non octet of bits ? , ? aborted frame ? , ? data overflow ? , ? maximum frame length exceeded ? and ? frames with less than or equal to two data bytes ? . an activated reception-hold in the descriptor prevents the munich32 from processing the receive data. the incoming frames are discarded until the hold is deactivated. because the munich32 is divided into two non-synchronized parts by the on-chip buffers, two different kinds of aborting a channel transmission are implemented. ? normal abort: this abort of a receive or transmit channel is processed in the formatters of the serial interface. the interframe time-fill code is sent after aborting the current issued frame. no accesses to the on-chip buffers are carried out, until the abort is withdrawn. the handling of the link lists and the processing of the buffers by the dma controller are not affected by normal abort. ? fast abort: a fast abort is performed by the dma controller and does not disturb the transmission on the serial interface. if this abort is detected the current descriptor is suspended with an abort status immediately followed by a branching to the new descriptor defined in the channel specification of the ccs. for initialization and control the host sets up a control and configuration section (ccs), including the action specification, interrupt queue specification, time slot assignment and the channel specification. the host initiates an action, e.g. reconfiguration, change of the channel mode, reset or switching of a test loop by updating the ccs and issuing an action request pulse. when the action request pulse is detected by the munich32 it reads the control start address, then the action specification and, if necessary, additional information from the ccs. after execution, the action request is acknowledged by an interrupt. munich32 indicates an interrupt by activating the interrupt line and storing the interrupt information including the corresponding channel number in the interrupt queue. the interrupt queue is a circular buffer; munich32 starts to write the interrupt queue specification and fills it successively in a circular manner. the host has to allocate sufficient buffer size and to empty the buffer fast enough in order to prevent overflow of the queue.
peb 20320 functional description user ? s manual 75 01.2000 monitoring functions are implemented in munich32 to discover errors or condition changes, i.e. ? receive frame end ? receive frame abort by overflow of the receive buffer or hold condition or recognized abort flag ? frame overflow, if a frame has to be discarded because of pending inaccessibility of the chip memory ? transmit frame end ? transmit frame abort (data underrun) by underrun of the transmit buffer or hold condition or bus cycle error ? change of the interframe time-fill. ? loss of synchronism or change of framing bits (v.110, x.30). ? short frame with no data content detected. an error or condition change is indicated by an interrupt. the host may react to the interrupt by either aborting or tristating the specific channel or with a channel reconfiguration. to prevent underrun of the transmit buffer sufficient buffer size has to be allocated to the channel. a more detailed discussion of the receive procedure with examples is provided under the detailed protocol description in chapter 2.4 .
peb 20320 functional description user ? s manual 76 01.2000 2.4 detailed protocol description in the following sections the protocol support of the munich32 is described in detail for transmit and receive direction separately. each section starts with a discussion of the general features proceeds with protocol variants and options from the channel specification and closes with a description of the interrupts and special topics. hdlc transmit direction general features in transmit direction ? the starting and ending flag (7e h before and after a frame) ? the interframe time-fill between frames ? the zero insertions (a ? 0 ? -bit after 5 consecutive ? 1 ? s inserted within a frame) ? (optional) the frame check sequence (fcs) at the end of a frame is generated automatically. options the different options for this mode are ? the kind of the interframe time-fill character in the channel specification ? 7e h for iftf = 0 ? ff h for iftf = 1 ? the number of interframe time-fill characters as fnum in the transmit descriptor. for the values fnum = 0, 1, 2 we have ? fnum = 0 frame 1, 7e h , frame 2 (start flag = end flag) ? fnum = 1 frame 1, 7e h , 7e h , frame 2 ? fnum = 2 frame 1, 7e h , ic, 7e h , frame 2 ? the correction of the number of interframe time-fill characters by 1 / 8 of the number of zero insertions by programming fa in the channel specification. ? fa = 0: fnum from the transmit descriptor is taken directly to determine the number of interframe time-fill characters as shown in figure 39 . ? fa = 1: fnum from the transmit descriptor is reduced by 1 / 8 of the number of the zero insertions of the frame corresponding to the transmit descriptor as shown in figure 40 . this allows for a more or less constant bit rate transmission for long hdlc frames.
peb 20320 functional description user ? s manual 77 01.2000 figure 40 note: 1. is the biggest integer smaller than . 1. for fnum ? < 0, y = 0 ? the kind of frame check sequence (fcs) two kinds of frame check sequences are implemented by the crc bit in the channel specification crc = 0: the generator polynomial x 16 + 12 +x 5 +1 is used (2 byte fcs of ccitt q.921) crc = 1: the generator polynomial x 32 +x 26 +x 23 +x 22 +x 16 +x 12 + x 11 + ? ? x 10 +x 8 +x 7 +x 5 +x 4 +x 2 +x + 1 (4 byte fcs) is used ? the suppression of the automatic generation of the fcs is programmable in the channel specification: ? cs = 0: fcs generated automatically cs = 1: fcs generation suppressed and in the transmit descriptor csm = 0: fcs generated automatically if cs = 0 in the channel specification csm = 1: fcs generation suppressed itd04579 fe=1 fnum data contents of frame 1 frame 2 of contents data 7e h frame 1 frame 2 x zero insertions h e 7 . . . . . . 7 e h y+1 [], max (fnum - 0) y= x 8 x 8 -- - x 8 -- - x 8 -- -
peb 20320 functional description user ? s manual 78 01.2000 interrupts the possible interrupts for the mode in transmit direction are: hi: issued if the hi bit is detected in the transmit descriptor (not maskable) fi: issued if the fe bit is detected in the transmit descriptor (maskable by fit in the channel specification) err: one of the following transmit errors has occurred: ? the last descriptor had h = 1 and fe = 0 ? the last descriptor had no = 0 and fe = 0 (maskable by te in the channel specification) fo: one of the following transmit errors have occurred ? a berr = ? 0 ? was detected during a read access to a transmit data section for this channel ? the munich32 was unable to access the shared memory in time either for new data to be sent or for a new transmit descriptor. (maskable by te in the channel specification) typical data stream has the form example: hdlc channel with cs = 0) (fcs generated automatically) inv = 0 (no inversion) crc = 0 (crc16) trv = 00 (required as unused in hdlc mode) fa = 1 (flag adjustment) mode = 11 (hdlc) iftf = 1 (interframe time-fill ? 1 ? s) intel interface channel number 1a ? itf flag data fcs flag itf ?
peb 20320 functional description user ? s manual 79 01.2000 figure 41 note: 1. data is transmitted according to 2.8 of ccitt recommendation q.921 2. note: fcs in the data section is formatted as ordinary data!!! 3. fcs is generated here automatically as cs = 0 and csm = 0 for the 1 st descriptor. 4. there was 1 zero insertion in the 1 st frame, so fnum ? =fnum=2. therefore between the first and the second frame we have flag itf flag and itf = ffh because iftf = 1. itd04578 a0010002 aa 0 31 ff ff ff ff 80060801 80030800 31 0 generate fi, hi-int. 2000081a 31 0 31 0 31 0 31 0 2000181a generate fi-int. 1 data 1 desc st nd 2 desc 3 desc rd 0 1 ff 00 address increases fe=1 hold=0 hi=1 no=1 csm=0 fnum=2 fnum=1 csm=1 no=6 hi=0 hold=0 fe=1 01111110 ..... 01010101 00010100010111110 01111110 11111111 flag time increases flag 3 itf zero insertion fcs 2 5 flag flag 01111110 111110111110111110111110111110111110111110111110 01111110 data 2 8 zero insertion 4 01111110 0101010100010100010111110 flag zero insertion data 3 generate fi-int. 2000081a fe=1 hold=0 hi=0 no=3 csm=1 fnum=0 00 aa fa 28 00000000 1 8 -- -
peb 20320 functional description user ? s manual 80 01.2000 5. no fcs is generated here as csm is ? 1 ? for the second and third transmit descriptor. the fcs is supposed to be the last 2 bytes to be transmitted in this case, their validity is not checked internally. 6. there was 8 zero insertions in the 2 nd frame, so fnum ? =fnum ? 1=0. therefore between the second and the third frame we have a shared flag. for cs = 1 (crc select) the transmitted data stream would differ at fcs, fcs would just be omitted. for inv = 1 (channel inversion) all bits of the data stream (including flag, data, fcs, itf) would be inverted. for crc = 1 (crc 32) the transmitted data stream would only differ in the fcs, the fcs would be 1101 0111 1010 0101 1000 0000 0010 0111. for fa = 0 (no flag adjustment) the transmitted data stream would change only after data 2. the value fnum = 1 in the second descriptor would alone determine the number of interframe time-fill characters, the scenario would look like figure 42 for iftf = 0 (itf flags) the transmitted data stream would only differ at itf, the 8 ones would be replaced by 0111 1110. for motorola interface the only difference is in the data section for the first descriptor it ought to be and for the second and for the third 31 0 aa 31 0 ff ff ff ff ff 00 31 0 aa 28 fa 8 8 -- - data 2 flag flag data 3 0111 111 0111 111
peb 20320 functional description user ? s manual 81 01.2000 hdlc receive direction general features in receive direction: 1. the starting and ending flag (7e h before and after a frame) is recognized and extracted. 2. a change of the interframe time-fill is recognized and reported by an interrupt. 3. the zero insertions (a ? 0 ? -bit after five ? 1 ? s within a frame) are extracted. 4. the fcs at the end of a frame is checked, it is (optionally) transferred to the shared memory together with the data. 5. the number of the bits within a frame (without zero insertions) is checked to be divisible by 8. 6. the number of bytes within a frame is checked to be smaller than mfl + 1 (after extraction of ? 0 ? insertions). 7. the number of bits within a frame after extraction of ? 0 ? insertions is checked to be greater than (case nsf = 0 only) 8. the occurrence of an abort flag (7f h ) ending a frame is checked. more detailed description of the individual features: 1. a. a frame is supposed to have started if after a sequence of 0111 1110 in the receive data stream neither fc h nor fd h nor 7e h has occurred. the frame is supposed to have started with the first bit after the closing ? 0 ? of the sequence. b. a frame is supposed to have stopped if a sequence of 0111 1110 or 0111 1111 is found in the data stream after the frame has started. the last bit of the frame is supposed to be the bit preceding the ? 0 ? in the above sequences. the cases of sequences 0111 1110 1111 111 and 0111 1110 0111 1111 are also supposed to be frames of bit length ? 1 and 0 respectively. a frame is also supposed to have stopped if more than mfl bytes were received since the start of the frame and it wasn ? t stopped yet. c. the ending flag of a frame may be the starting flag of the next frame (shared flags supported). (case nsf = 0 only) check a) 16 for crc = 0 32 for crc = 1 (only for cs = 0) check b) 32 for crc = 0 48 for crc = 1 (case nsf = 1 & cs = 1 only) check a ? ) 8 for crc = x (ignored)
peb 20320 functional description user ? s manual 82 01.2000 2. the receiver is always in one of two possible interframe time-fill states: to be called f and o. the following diagram explains them. a change from f to o and from o to f is reported by an ifc interrupt. figure 43 3. the ? 0 ? extraction is also carried out for the last 6 bits before the stopping sequence. 4. the last 16 (crc = 0) or 32 (crc = 1) bits of a frame (after extraction of the zero insertions are supposed to be the fcs of the remaining bits of the frame. (for the case of a frame with less than or equal to 16 or 32 bits respectively see discussion of 7). the fcs is always checked, the check is reported in the crco bit of the last receive descriptor of the frame crco = 1: fcs was incorrect crco = 0: fcs was correct. 5. the check is reported in the nob bit in the last receive descriptor of the frame nob = 1: the bit length of the frame was not divisible by 8. nob = 0: the bit length of the frame was divisible by 8. if nob = 1: the last access to a receive data section of the frame may contain erroneous bits and shouldn ? t be evaluated. 6. the check is reported in the lfd bit in the last receive descriptor of the frame. lfd = 1: the number of bytes was greater than mfl. lfd = 0: the number of bytes was smaller or equal to mfl. only the bytes up to the mfl + 1 st one for cs =1 mfl ? 1 st one for cs = 0, crc = 0 mfl ? 3 rd one for cs = 0, crc = 1 are transferred to be stored memory. the bytes of the last access may be erroneous and shouldn ? t be evaluated. itd04577 reset or receive off o f receive initialize channel command 111111111111111 in the data stream (15 contiguous "1"s received) or a receive abort channel command during 15 received bits supported) shared zeros received, flags with (2 contiguous flags in the data stream 0111111001111110 011111101111110 or
peb 20320 functional description user ? s manual 83 01.2000 7. for frames not fulfilling check a) no data are transferred to the shared memory irrespective of cs. only an interrupt with the bit fi, sf and (possibly) err is generated. for frames fulfilling check a) but not check b) data is transferred to the shared memory but the sf bit in the last receive descriptor is set. 8. the check is reported in the ra bit in the last receive descriptor of the frame ra = 1: the frame was stopped by the sequence 7f h ra = 0: the frame was not stopped by the sequence 7f h . note: a receive descriptor with ra = 1 may also result from a fast receive abort or a receive abort channel command or from a receive descriptor with set hold bit. options the different options for this mode are: ? the kind of frame check sequence (fcs) two kinds of fcs are implemented and can be chosen by crc bit. crc = 0: the generator polynomial x 16 +x 12 +x 5 + 1 is used (2 byte fcs of ccitt q.921) crc = 1: the generator polynomial x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x + 1 (4 byte fcs) is used. ? the transfer of the fcs together with the received data is programmable by the cs bit. cs = 0: fcs is not transferred to the data section cs = 1: fcs is transferred to the data section. note: fcs is always checked irrespective of the cs bit. interrupts the possible interrupts for the mode in receive direction are: hi: issued if the hi bit is detected in the receive descriptor (not maskable) fi: issued if a received frame has been finished as discussed in 1.b of the protocol features (also for frames which do not lead to data transfer as discussed in 7. of the protocol features) (maskable by fir in the channel spec.) ifc: issued if a change of the interframe time-fill state as discussed in 2. has occurred. (maskable by ifc in the channel spec.) sf: a frame not fulfilling check a) has been detected (maskable by sfe in the channel spec.)
peb 20320 functional description user ? s manual 84 01.2000 err: issued if one of the following error conditions has occurred: ? fcs was incorrect ? the bit length was greater than mfl ? the frame was stopped by 7f h ? the frame could only be partly stored because of internal buffer overflow of rb ? a fast receive abort channel command was issued ? a receive abort channel command was detected during reception of a frame ? a frame could only be partly transferred to the shared memory because of a receive descriptor with hold bit set (maskable by re in the channel spec.) fo: issued if due to inaccessibility of internal buffer rb ? one ore more complete frames have been lost ? one ore more changes of interframe time-fill state were lost (maskable by re in the channel spec.) example: hdlc channel with cs = 1 (fcs transferred to shared memory) inv = 0 (no inversion) crc = 1 (crc 32) trv = 00 (required as unused in hdlc mode) fa = x (irrelevant) mode = 11 (hdlc) iftf = x (irrelevant) motorola interface channel no. 1d mfl = 10
peb 20320 functional description user ? s manual 85 01.2000 figure 44 itd04576 0 31 20080000 0 31 nd 2 desc 40080000 8800203d c0031c00 1 desc st 000c0000 31 0 last access of a lfd frame generate hi-int. 0 31 crco, nob, generate fi, err-int. 8800123d should be ignored c2 a1 01 03 39 80 3d bc data 2 lfd 4 ..... 01111110 1000 0101 1000 0000 1100 0000 1001 1100 0000 0001 0100 0011 1101 0011 0100 0010 1011 1101 0011 0110 1000 0011 11100 0011 10111100 01111111 1 flag data 1, fcs 1 2 data ignored up to next flag abort sequence 3 5
peb 20320 functional description user ? s manual 86 01.2000 figure 45 itd04575 0 31 200c0000 0 31 rd 3 desc c0080000 8800303d c0081800 4 desc th 000c0000 31 0 last access of a nob frame generate fi, hi-int. 0 31 fb 49 ac 00 crco, nob generate fi, err-int. 8800123d should be ignored 00 ac 49 fb c0 a4 f2 fa data 2 fcs 2 data 3 01111110 0011 0101 1001 0010 1101 1111 0 0000 0000 flag data 2 6 2 fcs 0011 0000 0 1111 0101 1111 0100 0101 0010 0011 0101 1001 0010 1101 1111 0 0000 0000 data 3 flag 01111110 0010 0101 0100 1111 0101 1111 0000 0011 fcs 3 01111110 flag zero insertion (shared) zero insertion zero insertion zero insertion missing
peb 20320 functional description user ? s manual 87 01.2000 figure 46 note: 1. after receive initialization is detected all data are ignored until a flag is received. the receiver is in the interframe time-fill state ? 0 ? . 2. after mfl + 1 data bytes are received the further data are ignored (except for a change of the interframe time-fill state) and are neither stored in the rb nor reported to the shared memory. the receiver waits for the next flag. 3. even the abort sequence at the end of the frame will not lead to the ra bit in the descriptor to be set. 4. data are formatted according to 2.8 of ccitt q.921. 5. the fcs is formatted as ordinary data!!! itd04574 000c0000 aa 7b a5 01 0 31 01 a5 7b aa 00140000 31 0 (15 1) 8800083d 31 0 31 0 8800143d generate short fcs 4 5 desc th th 6 desc c0050200 c0050000 ra 8 1 1111 data ignored up to next flag 7 15 e4 xx xx xx xx xx xx e4 10 data 4 generate ifc-int. 8800083d generate ifc-int. 8800123d 8800103d generate fi-int. generate fi, err-int. (2 flags) 9 frame interrupt for fcs 5 * 11 1111110101000110011100111010 0111 01110 1111 1111 x "1" 5 1010 0101 1000 0000 0010 0111 1101 1110 data 4 5 fcs 0000 0000 0000 0000 0000 0000 0000 0000 0101 0101 fcs 4 0111 1110 111 1110 2 flags with shared 0 flag 01111110 0101 0101 6 data 01111110 flag fcs 6 01111111 abort sequence 1101 1110 1010 0101 1000 0000 0010 0111 generate short frame interrupts 8800163d 8800163d 011111100011111101111111 12
peb 20320 functional description user ? s manual 88 01.2000 6. lfd is issued and always accompanied by nob. crco shouldn ? t be interpreted for a lfd frame. 7. here the ending flag of the second frame is the starting flag of the third frame. 8. after an abort sequence data is ignored until a flag is found (except for a change of the interframe time-fill state). they are neither stored in the rb nor reported to the shared memory. 9. the last 3 bytes in the last write access to the receive data section of the 5th descriptor have to be ignored. 10.the 2 flags with a shared 0 in the middle change the original interframe time- fill state ? 0 ? of the receiver to ? f ? . the 2 flags following fcs 5 on the other hand do not change the interframe time-fill state, as it already was ? f ? . 11.the frame consisting only of 32 times 0 between 2 flags does not pass check a). it only leads to an interrupt. 12.the 15 ? 1 ? leads to a change of the interframe time-fill state from ? f ? to ? 0 ? even through it is in a data ignored zone. 13.this frame of length ? 1 leads to an interrupt. for cs = 0 (crc not select) the descriptor would have looked like figure 47 itd04572 0 31 20080000 0 31 03 01 a1 c2 st 1 desc c0071c00 hi, 8800323d 8800303d generate hi, c0040000 desc 3 rd 00 ac 49 fb 31 0 200c0000 31 0 last access of a lfd frame should be ignored 2 fi-int. generate fi, err-int. 1
peb 20320 functional description user ? s manual 89 01.2000 figure 48 note: 1. only the 7 leading bytes are reported (the last 4 are supposed to be the fcs even in this case). 2. it is assumed here for convenience that the first descriptor points to the third and not to the second descriptor as in the original example. for inv = 1 (channel inversion) all bits of the data stream (including data, fcs, flag, abort sequence 15 ? 1 ? ) are interpreted inversely. e.g. ? 1000 0001 ? would be interpreted as flag 15 ? 0 ? would lead to a change from interframe time-fill state ? f ? to ? 0 ? etc. itd04573 0 31 000c0000 0 31 th 4 desc c0041800 8800123d c0014000 5 desc th 000c0000 31 0 c0014200 6 desc th aa xx xx xx 31 0 00140000 31 0 sf last access of a nob frame should be ignored generate fi, err-int. 0 31 xx xx xx aa crco, nob sf, ra interrupts as in the original example
peb 20320 functional description user ? s manual 90 01.2000 for crc = 0 (crc 16) the correct fcs e.g. zeros for data 4 would be 00001 0100 0101 1110 the 5 th descriptor would then be figure 49 for intel interface the only difference is in the receive data sections. they would be figure 50 itd04570 0 31 000c0000 0 31 xx fa 28 aa th 5 desc c0034000 itd04571 03 01 a1 c2 0 31 fb 49 ac 00 31 0 0 31 aa 7b a5 01 1 st desc 3 rd desc th 5 desc of of of xx xx xx e4 c0 a4 f2 fa 39 80 30 bc
peb 20320 functional description user ? s manual 91 01.2000 tmb transmit direction general features in transmit direction: ? the starting and ending flag (00 h before and after a frame) ? the interframe time-fill between frames is generated automatically. options the different options for this mode are: ? the number of interframe time-fill characters as shown in figure 26 by choosing fnum in the transmit descriptor. for the values fnum = 0, 1, 2 we have fnum = 0 ? frame 1, 00 h , frame 2 ? (start = end flag) fnum = 1 ? frame 1, 00 h , 00 h , frame 2 ? fnum = 2 ? frame 1, 00 h , 00 h , 00 h , frame 2 ? interrupts the possible interrupts for the mode in transmit direction are identical to those of hdlc. a typical data stream has the form itf data itf data example tmb channel with inv = 0 (no inversion) crc = 0 (required) trv = 00 (required) fa = 0 (required) mode = 01 (tmb) iftf = 0 (required) intel interface channel number 5
peb 20320 functional description user ? s manual 92 01.2000 figure 51 note: 1. data is transmitted according to q.921 2.8 and fully transparent. 2. a transmit descriptor with no = 0 and fe = 1 is allowed, one with no = 0 and fe = 0 is forbidden. 3. fnum = 1 leads to 2 flags after data 2. itd04569 20020000 0 ce ab 0 31 80000000 80030001 45 23 01 31 0 generate fi-interrupt 88001005 31 0 31 0 31 0 88002005 generate hi-interrupt 0 00 2 4a 0c 8 00 73 5 d 0 0 ..... ..... data 2 1 data 1 88001005 generate fi-interrupt flag flag 00 2 flags 2 3
peb 20320 functional description user ? s manual 93 01.2000 tmb receive direction general features 1. the starting and ending flag (00 h before and after a frame) as well as interframe time- fill is recognized and extracted. 2. the number of bits within a frame is checked to be divisible by 8. 3. the number of bytes within a frame is checked to be smaller than mfl + 1. 4. a frame containing less than 8 bits may be ignored completely by the receiver. more detailed description of the individual features: 1. a. a frame is supposed to have started if after a sequence ? 0000 0000 ? a ? 1 ? -bit is recognized. the frame is supposed to have this ? 1 ? -bit as first bit. b. a frame is supposed to have stopped if ? either a sequence 0000 0000 1 is found in the data stream after the frame has started ? or a sequence 0000 0000 is found octet synchronous (i.e. the first bit of the sequence 00 h is the 8 m + 1 st bit since the starting ? 1 ? -bit of 1.a. for an integer m). in both cases the last bit before the sequence 00 h is supposed to be the last bit of the frame. 2. the check is reported in the nob bit in the last receive descriptor of the frame. nob = 1: the bit length of the frame was not divisible by 8. nob = 0: the bit length of the frame was divisible by 8. 3. the check is reported in the lfd bit in the last receive descriptor of the frame. lfd = 1: the number of bytes was greater than mfl. lfd = 0: the number of bytes was smaller or equal to mfl. only the bytes up to the mfl + 1 st one are transferred to the shared memory. the bytes of the last access to the receive data section of the frame may contain erroneous bits and shouldn ? t be evaluated. lfd is always accompanied by nob. options there are no options in receive direction for this mode.
peb 20320 functional description user ? s manual 94 01.2000 interrupts the possible interrupts for the mode in receive direction are: hi: issued if hi bit is detected in the receive descriptor (not maskable). fi: issued if a received frame has been finished as discussed in 1b) of the protocol features or a receive abort channel command was detected during reception of a frame. (maskable by fir in the channel spec.) err: issued if one of the following error conditions has occurred ? the bit length of the frame was not divisible by 8 ? the byte length was greater than mfl ? the frame could only be partly stored because of internal buffer overflow of rb ? a fast receive abort channel command was issued ? the frame could only be partly transferred due to a receive descriptor with set hold bit. (maskable by re in the channel specification) fo: issued if due to inaccessibility of the internal buffer rb one or more complete frames have been lost. (maskable by re in the channel spec.) example: tmb channel with inv = 0 (no inversion) crc = 0 (required) trv = 00 (required) fa = 0 (required) mode = 01 (tmb) iftf = 0 (required) mfl = 7 motorola interface channel no. a
peb 20320 functional description user ? s manual 95 01.2000 figure 52 itd04568 00040000 9d 01 xx xx 0 31 xx xx xx d3 200c0000 20080000 31 0 generate fi, 8800302a 31 0 31 0 31 0 31 0 8800102a generate fi-int. data 3 1 data data 2 1 st desc desc nd 23 rd desc 8800322a c0020800 c0010000 c0020000 nob 2 hi-int. hi, generate fi, err-int. last access of a nob frame should be ignored 11110111 01010101 0000 0000 0000 10101101 00101010 0000 0000 data ignored up to next framestart 5 flag flag data 5 data 4 10000000 10111100 0000000 11111110 01111111 11111011 11010101 01001100 10100000 flag synchronous non octet 4 00000000 10111001 10000000 00000000 00 3 11001011 00000000 10000000 data 1 data 2 data 3 flag flag flag octet synchronous octet synchronous 1 (start) flag
peb 20320 functional description user ? s manual 96 01.2000 figure 53 note: 1. after receive initialization is detected all data are ignored until the starting sequence 0000 0000 1 is detected. 2. data are formatted according to 2.8 of ccitt q.921. 3. the octet synchronous (end) flag of one frame can be part of the (start) flag of the next frame. between data 1 and data 3 they are identical (shared flags supported). 4. here the sequence 0000 0000 1 is detected non-octet synchronously. therefore the frame belonging to data 3 is supposed to have ended non-octet synchronously (nob set in the 3 rd descriptor). 5. after mfl + 1 data bytes the further data are ignored and are neither stored in the rb nor reported to the shared memory. the receiver waits for the next sequence 0000 0000 1 to come. 6. if a receive descriptor is full (4 th desc.) the munich32 branches to the next receive descriptor (5 th desc.) even if no further data are to be given to the shared memory. itd04567 0 31 20080000 0 31 df fe 7f 01 data 4 th 4 desc 40080000 generate hi-int. 8800202a 8800122a c0000c00 desc 5 th 00040000 31 0 8800102a generate fi-int. c0020000 desc 6 th b5 54 xx xx 31 0 00fc0000 31 0 lfd, last access of a lfd frame should be ignored generate fi, 6 nob err-int. data 5
peb 20320 functional description user ? s manual 97 01.2000 for inv = 1 (channel inversion) all bits of the data stream (including data, flag) are interpreted inversely e.g. 1111 1111 0 would be interpreted as starting sequence then. for intel interface the only difference is in the receive data sections. they would be figure 54 itd05034 xx xx xx d3 0 31 df fe 7f 01 31 0 0 31 b5 54 xx xx of 2 desc nd of 4 desc th th of 6 desc st of 1 desc 31 0 9d 01 xx xx
peb 20320 functional description user ? s manual 98 01.2000 tmr transmit direction general features in transmit direction ? the starting and ending flag (00 00 h or 0 00 h between frames) is generated automatically. options the different options for this mode are ? the number of interframe time-fill characters as shown in figure 29 by choosing fnum in the transmit descriptor. for the values 0, 1, 2 we have fnum = 0 ? frame 1, 000 h , frame 2 ? fnum = 1 ? frame 1, 00 h , 00 h , frame 2 ? fnum = 2 ? frame 1, 00 h , 00 h , 00 h , frame 2 ? by choosing fnum = 0 and setting the last transmitted nibble in the transmit data section to 0 h frames of effective length n + 1 / 2 bytes can be sent as required by gsm 08.60. interrupts the possible interrupts for the mode in the transmit direction are identical to those of hdlc. a typical data stream has the form itf data itf data example: tmr channel with inv = 0 (no inversion) crc = 1 (required) trv = 00 (required) fa = 0 (required) mode = 01 (tmr) iftf = 0 (required) intel interface channel no. 5
peb 20320 functional description user ? s manual 99 01.2000 figure 55 note: 1. data is transmitted according to q.921 2.8 and fully transparent. 2. a transmit descriptor with no = 0 and fe = 1 is allowed, one with no = 0 and fe = 0 is forbidden. 3. fnum = 1 leads to 2 flags after data 2. itd04566 20020000 0 0e ab 0 31 80000000 80030001 45 23 01 31 0 generate fi-interrupt 88001005 31 0 31 0 31 0 88002005 generate hi-interrupt 0 00 2 4a 0c 8 00 70 5 d 0 0 ..... ..... data 2 1 data 1 88001005 generate fi-interrupt flag flag 00 2 flags 2 3 frame of effective length 1 byte / 2 1
peb 20320 functional description user ? s manual 100 01.2000 tmr receive direction general features 1. the starting and the ending flag (00 00 h ) is recognized. interframe time-fill, both characters of the starting flag and the last character of the ending flag is extracted. 2. the number of bits within a frame is checked to be divisible by 8. 3. the number of bytes within a frame is checked to be smaller than mfl. more detailed description of the individual features 1. a. a frame is supposed to have started after a sequence of 16 zeros a ? 1 ? -bit is recognized. the frame is supposed to have this ? 1 ? -bit as first bit. b. a frame is supposed to have stopped if ? either a sequence of 16 ? zeros ? and a ? one ? is found in the data stream after the frame has started ? or a sequence of 16 zeros is found octet synchronous (i.e. the first bit of the sequence 00 00 h is the 8m + 1 st bit since the starting ? 1 ? -bit of 1.a. for an integer m). in both cases the eighth bit of the sequence 00 00 h is supposed to be the last bit of the frame. 2. the check is reported in the nob bit in the last receive descriptor of the frame. nob = 1 the bit length of the frame was not divisible by 8. nob = 0 the bit length of the frame was divisible by 8. if nob = 1 the last byte of the last access to a receive data section of the frame may contain erroneous bits and shouldn ? t be evaluated. this does not affect the reception of frames with n + 1 / 2 octets 3. the check is reported in the lfd bit in the last receive descriptor of the frame. lfd = 1 the number of bytes was greater than mfl. lfd = 0 the number of bytes was smaller or equal to mfl. mfl + 1 st one are transferred to the shared memory. the bytes of the last access to the receive data section of the frame may contain erroneous bits and shouldn ? t be evaluated. lfd is always accompanied by nob.
peb 20320 functional description user ? s manual 101 01.2000 options there are no options in receive direction for this mode. interrupts the possible interrupts for the mode in receive direction are identical to those of tmb. example: tmr channel with inv = 0 (no inversion) crc = 1 (required) trv = 00 fa = 0 mode = 01 (tmr) iftf = 0 (required) mfl = 7 motorola interface channel no. 15
peb 20320 functional description user ? s manual 102 01.2000 figure 56 itd04565 00040000 9d 01 00 xx 0 31 xx xx 00 d3 200c0000 00080000 01 00 3d af 31 0 generate fi, hi-int. 88003035 31 0 31 0 31 0 31 0 88001035 generate fi-int. 0 31 20080000 0 31 56 9a fb 8f data 4 data 3 1 data data 2 1 st desc desc nd 23 rd desc th 4 desc 88001235 c0060800 c0020000 c0030000 03 xx xx xx nob last byte of a nob frame should be ignored 40080000 generate hi-int. 88002035 88003235 fi, c0000c00 desc 5 th 20040000 31 0 88001035 generate fi-int. c0030000 desc 6 th bb 5e 00 xx 31 0 00080000 31 0 lfd, last access of a lfd frame should be ignored generate 6 5 nob hi, err-int. generate fi, err-int. data 5 (end) flag synchronous octet 5 data 11011101 01111010 00000000 00000000 4 data 00000000 00000000 11111111 11011011 11011101 11110111 11110011 01101010 11110001 11011111 01011001 0000 synchronous flag non octet 00000000 2 data 00000000 11001011 00000000 2 (end) flag 00000000 (start) flag .... 00000000 00000000 (start) flag 1 octet synchronous flag 1 data 3 10000000 10111001 00000000 11000000 11110101 10111100 00000000 10000000 3 data 4 up to next framestart data ignored 0000 octet synchronous
peb 20320 functional description user ? s manual 103 01.2000 1. after receive initialization is detected all data are ignored until a starting sequence (16 ? zeros ? , ? one ? ) is detected. 2. the octet synchronous (end) flag of one frame can be part of the (start) flag of the next frame. note, that the first 00 h character of the end flag is stored in the receive data section as ordinary data and is included in bno. between data 2 and data 3 the start and end flag are identical (shared flags supported). 3. here the start sequence is detected non-octet synchronously within a frame. therefore the frame belonging to data 3 is supposed to have ended non-octet synchronously (nob set in the 3 rd descriptor). 4. after mfl + 1 data bytes the further data are ignored and are neither stored in the rb nor reported to the shared memory. 5. data are formatted according to 2.8 of ccitt q.921. 6. if a receive descriptor is full (4 th descriptor) the munich32 branches to the next receive descriptor (5 th descriptor) even if no further data are to be given to the shared memory. for inv = 1 (channel inversion) all bits of the data stream (including data, flag) are interpreted inversely e.g. 16 ? ones ? , ? zero ? is interpreted as starting sequence then. for intel interface the only difference is in the receive data sections. they would be figure 57 itd05035 xx xx 00 d3 0 31 56 9a fb 8f 31 0 0 31 bb 5e 00 xx nd th th of 1 desc st 31 0 9d 01 00 xx rd 0 31 01 00 3d af xx xx xx 03 of 2 desc of 3 desc of 4 desc of 6 desc
peb 20320 functional description user ? s manual 104 01.2000 tma transmit direction general features in the transmit direction ? a slot-synchronous transparent data transmission ? a high impedance overwrite for the masked bits in the slot ? a programmable number of programmable fill characters between data (also slot synchronous) is generated automatically. options the different options for this mode are ? the value of the fill-character can be programmed for fa = 1 in the channel specification. the fill-character (tc) is then programmed in the tflag. for fa = 0 the fill character is ff h and tflag has to be set to 00 h . if subchanneling is chosen (not all fill/mask bits of the channel are ? 1 ? ) fa must be set to ? 0 ? . ? the number of inter-data time-fill characters as shown in figure 33 by choosing fnum = 0, 1, 2 we have fnum = 0 ? data 1, tc, data 2 ? fnum = 1 ? data 1, tc, tc, data 2 ? fnum = 2 ? data 1, tc, tc, tc, data 2 ? interrupts the possible interrupts for this mode in transmit direction are identical to those of hdlc.
peb 20320 functional description user ? s manual 105 01.2000 example 1: (no subchanneling by fill/mask bits) tma channel with tflag = b2 h inv = 0 (no data inversion) crc = 0 (required) trv = 00 (required) fa = 1 (flag filtering) mode = 00 (tma) iftf = 0 (required) all fill-mask bits are ? 1 ? for this channel (no high impedance overwrite) intel interface channel no. d figure 58 note: 1. data are formatted according to 2.8 of q.921. the tc is transmitted msb (bit 15) first though!!! 2. fnum = 0 in the second descriptor leads to the insertion of the tc after data 2, fnum = 1 in the third descriptor to the insertion of 2 tcs. itd04564 20020000 0 xx xx d1 ab 0 31 36 12 00 xx a0030000 80010001 xx xx xx f2 31 0 generate hi-, fi-interrupt 8800300d 31 0 31 0 31 0 31 0 8800200d generate hi-interrupt 0 31 00030000 0 31 d1 2d 32 xx 000 data 4 data 3 1 data data 2 1 st desc desc nd 23 rd desc th 4 desc 4 b 0 7 0 7 4c 8b 7 0 b2 7 0 b2 7 0 4f 7 0 b2 7 0 00 7 0 48 7 0 6c b 8 5 d 70 0 boundaries time-slot bit no 70 70 ..... ..... data 2 1 data 4 data data 3 1 2 tc 2 tcs for inv=1 data and tc would be inverted
peb 20320 functional description user ? s manual 106 01.2000 for inv = 1 the data stream would be inverted completely figure 59 for fa = 0 tflag has to be programmed to 00 h and the data stream would be figure 60 for motorola mode the data sections leading to the same data stream would have been figure 61 data 1 data 2 tc data 3 2 tcs data 4 ? 2a 74 93 b7 ff 4d b0 4d 4d 74 4b b3 ? data 1 data 2 tc data 3 2 tcs data 4 d5 8b 6c 48 00 ff 4f ff ff 8b b4 4c itd05036 36 12 00 xx 0 31 d1 2d 32 xx 31 0 th of 1 desc st 31 0 xx xx d1 ab rd 0 31 xx xx xx f2 of 2 desc nd of 3 desc of 4 desc
peb 20320 functional description user ? s manual 107 01.2000 example 2: (subchanneling by fill/mask bits) tma channel with tflag = 00 h (required for this case) inv = 0 (no data inversion) crc = 0 (required) trv = 00 (required) fa = 0 (required for subchanneling) mode = 00 (tma) iftf = 0 (required) intel interface channel no. d figure 62 itd04563 20020000 0 xx xx d1 ab 0 31 36 12 00 xx a0030000 80010001 xx xx xx f2 31 0 generate hi-interrupt 8800200d 31 0 31 0 31 0 31 0 8800200d generate hi-interrupt 0 31 00030000 0 31 d1 2d 32 xx 000 data 4 data 3 1 data data 2 1 st desc desc nd 23 rd desc th 4 desc
peb 20320 functional description user ? s manual 108 01.2000 figure 63 note: example 2 uses the same descriptors as example 1. those bits in the data stream that are at places where fill/mask is ? zero ? are overwritten by ? z ? i.e. high impedance. in all other protocols bits of the data stream are not overwritten by fill/mask zero bits. instead the whole data stream is sent at fill/mask one bits for all other protocols. itd04562 01234567 slot boundaries fill/mask high imp. overwrite external data internal data 1 1 1 0 1 1 1 1 1 1 1 1 1 z 1 1 1 0 1 10 1 0 0 1 7 6 5 4 3 2 1 07 6 5 4 3 2 1 07 6 5 4 3 2 1 07 6 5 4 3 2 1 07 6 5 4 3 2 1 0 bit no 10 1 11 11 z 1 0000 z0 1 1 1 1 1 1 1 1 1 110 01 0z data 3 (4f) b4 (8b 4 data tcs 4c) 11 1 0 0 0 0zz 1 1111 0 0 111111111111 111 11110 z 1010011 zzz 111 10 1 1 11 11 1111 0001 11 1 10 111 1 11 1 0 0 00 0 0 00 0 1 (ff ff) 2 itd04561 01234567 slot boundaries fill/mask high imp. overwrite external data (tdata) internal data 1 0 1 0 1 00 0 0 0 1 1 1 1 1 1 1 1 z 1 10 1 z 1 0 z z 1 z 0 1 1 0 0 1 0 110101011 0111010100 011 1 7 6 5 4 3 2 1 07 6 5 4 3 2 1 07 6 5 4 3 2 1 07 6 5 4 3 2 1 07 6 5 4 3 2 1 0 bit no 111010 1 0 11 11 1 0 00 00 000 0 0 0 z z z z z z z0 111 000 00 0 000 z010z z z 00 0 000 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1100 011 0zz data 1 (d5 8b) 48 (6c 2 data tc (ff) 00)
peb 20320 functional description user ? s manual 109 01.2000 tma receive direction general features in the receive direction ? a slot synchronous transparent data reception ? a ? 1 ? overwrite for masked bits in the slot ? for fa = ? 1 ? a slot synchronous programmable flag extraction is performed automatically. options the different options for this mode are: ? the programmable character tc to be extracted for fa = ? 1 ? is tflag. for fa = ? 0 ? nothing is extracted. if subchanneling is chosen (not all fill/mask bits of the channel are ? 1 ? ) fa must be set to ? 0 ? . interrupts the possible interrupts for the mode in receive direction are: hi: issued if the hi bit is detected in the receive descriptor (not maskable). err: issued if a fast receive abort channel command was issued. (maskable by re in the channel spec.) fo: issued if data could only partially stored due to internal buffer overflow of rb. (maskable by re in the channel spec.) example 1: (no subchanneling) tma channel with tflag = d7 inv = 0 (no channel inversion) crc = 0 (required) trv = 00 (required) fa = 1 mode = 00 (tma) iftf = 0 motorola interface channel no. e
peb 20320 functional description user ? s manual 110 01.2000 figure 64 note: the fe bit is never set in a receive descriptor. the data are formatted according to 2.8 q.921. for fa = 0 (and therefore tflag = 00 h ) the descriptor would be figure 65 itd04560 00040000 40040000 6b f5 bd 00 0 31 1e be c6 14 40040000 20040000 31 0 generate hi-interrupt 8800202e 31 0 31 0 slot boundaries 0 0 7 d6 d7 f a 0 7 d b 0 7 0 0 0 7 7 d 0 7 7 d 0 7 8 2 0 7 3 6 0 7 7 d 8 7 70 70 7d octet synchr. tc tcs synchr. 2 octet tc synchr. octet not octet synchr. tc not filtered itd04559 00040000 40040000 6b eb f5 bd 0 31 14 eb eb 00 40040000 20040000 00040000 40040000 c6 eb be 1e 31 0 generate hi-interrupt 8800202e 31 0 31 0 31 0 31 0
peb 20320 functional description user ? s manual 111 01.2000 for inv = 1 the receiver filters the inverse of the tflag as tc out of the data stream and inverts the data (only the octet synchronous 28 h would be filtered). for intel interface the data sections would be for the first descriptor and for the second. example 2: (with subchanneling) tma channel with tflag = 00 h (required because of subchanneling) inv = 0 (no channel inversion) crc = 0 (required) trv = 00 (required) fa = 0 (required because of subchanneling) mode = 00 (tma) iftf = 0 motorola interface channel no. e 00 bd f5 6b 1e be c6 14
peb 20320 functional description user ? s manual 112 01.2000 figure 66 itd04558 11 00040000 40040000 00 ef f7 d6 0 31 111111010011000101100010111101 slot boundaries fill/mask "one" overwrite external data (rdata) internal data for inv=1 1 0 0 1 0 1 0 0 1 0 0 1 0 1 1 1 0 1 1 0 0 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 0 1 10 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 000000001 11 0 111 10 11101 1 00 1 1 0111 1 0110 31 0
peb 20320 functional description user ? s manual 113 01.2000 v.110/x.30 transmit direction general features in transmit direction ? the synchronization pattern for v.110/x.30 frame as shown in table 1 . ? the framing for the different data rates with programmable e-, s-, x-bits ? sending ? 0 ? before all frames is performed automatically. table 1 synchronization pattern for v.110/x.30-frames the e-, s-, x-bits are fed into the data stream by special transmit descriptor (as shown in figure 30 ), they can only change from one 10-octet frame to the next, not within a 10- octet frame. the data from the data sections are supposed to come in the form: 31 0 1 1 b6 b5 b4 b3 b2 b1 1 1 b12 b11 b10 b9 b8 b7 1 1 b18 b17 b16 b15 b14 b13 1 1 b24 b23 b22 b21 b20 b19 (for motorola mode), 31 0 1 1 b24 b23 b22 b21 b20 b19 1 1 b18 b17 b16 b15 b14 b13 1 1 b12 b11 b10 b9 b8 b7 1 1 b6 b5 b4 b3 b2 b1 (for intel mode). where for 600 bit/s e.g. b1 to b6 belong to the first 10-octet frame, b7 to b12 belong to the second 10-octet frame, etc. octet no.12345678 1 2 3 4 5 6 7 8 9 10 00000000 1 1 1 1 1 1 1 1 1
peb 20320 functional description user ? s manual 114 01.2000 options the different options for this mode are: ? the framing pattern, as shown in table 2 to table 5 , is programmed by the bits trv. interrupts hi: issued if the hi bit is detected in the transmit descriptor (not maskable) err: if one of the following transmit errors has occurred ? the last descriptor had fe = 1 (leads to an abort of the transmit data, see figure 31 ) ? the last descriptor had h = 1 (see figure 29 ) ? the last descriptor had no = 0 (maskable by te in the channel spec.) fo: one of the following transmit errors has occurred ? a berr = ? 0 ? was detected during a read access to a transmit data section for this channel ? the munich32 was unable to access the shared memory in time either for new data to be sent or for a new descriptor. (maskable by te in the channel spec.)
peb 20320 functional description user ? s manual 115 01.2000 example x.30/v110 channel with cs = 0 (required) inv = 0 crc = 0 trv variable (all values shown in examples) fa = 0 (required) mode = 10 (v.110/x.30) intel interface channel no. 1f figure 67 note: the first transmit descriptor must have the v.110-bit set. itd05037 00028000 0 75 40 00 00 0 31 c3 d6 fa xx 20030000 20018000 8a 80 00 00 31 0 generate hi-interrupt 8800201f 31 0 31 0 31 0 31 0 0 31 00030000 0 31 c0 e2 d1 xx 000 data 2 e, s, x 2 1 e, s, x data 1 880201f generate hi-interrupt
peb 20320 functional description user ? s manual 116 01.2000 trv = 00 0000 0000 1111 1110 1111 1111 1111 1000 1000 0001 1010 1110 1000 0000 1000 0001 1000 0000 1000 0001 0000 0000 1000 0000 1001 1111 1111 1110 1111 1111 1010 1110 1000 0000 1001 1111 1111 1000 1000 0001 0000 0000 1000 0000 1001 1111 1111 1000 1000 0001 1010 1110 1111 1110 1111 1111 1111 1110 1111 1111 0000 0000 1000 0001 1000 0000 1000 0001 1000 0000 1101 0001 1000 0001 1000 0000 1000 0001 1000 0000 0000 0000 1000 0001 1001 1110 1111 1001 1000 0000 1101 0001 1000 0001 1000 0000 1000 0111 1111 1110 0000 0000 1111 1111 1110 0000 1000 0001 1000 0000 1101 0001 1000 0001 1001 1110 1111 1001 1000 0000 d6 = 11 0 1 0 1 1 0 b6b5b4b3b2b1 fa = 11 1 1 1 0 1 0 b6b5b4b3b2b1 change of e-, s-, x-bits sa x sb 1 e1e2e3e4e5e6e7
peb 20320 functional description user ? s manual 117 01.2000 trv = 01 trv = 10 0000 0000 1111 1110 1110 0001 1000 0000 1000 0001 1010 1110 1000 0110 1111 1111 1000 0110 1110 0001 0000 0000 1000 0110 1110 0001 1111 1110 1111 1111 1010 1110 1000 0000 1000 0001 1000 0000 1000 0001 0000 0000 1000 0111 1110 0000 1000 0001 1001 1110 1101 0001 1111 1001 1000 0000 1000 0111 1110 0000 e2 = 1 1 1 0 0 0 1 0 b6b5b4b3b2b1 d1 = 1 1 0 1 0 0 0 1 b6b5b4b3b2b1 change of e-, s-, x-bits fa (last byte of data 1) 1 1 1 1 1 0 1 0 b6b5b4b3b2b1 1 1 0 0 0 0 0 0 b6b5b4b3b2b1 c0 (first byte of data 2) sa x sb 1 e1e2e3e4e5e6e7 0000 0000 1111 1000 1000 0001 1001 1110 1001 1001 1010 1110 1001 1000 1111 1111 1000 0000 1000 0001 0000 0000 1001 1001 1000 0110 1110 0001 1001 1000 1101 0001 11 10 11 10 sa x sb 1 e1e2e3e4e5e6e7 e2 = 1 1 1 0 0 0 1 0 b6b5b4b3b2b1 d1 = 1 1 0 1 0 0 0 1 b6b5b4b3b2b1 change of e-, s-, x-bits
peb 20320 functional description user ? s manual 118 01.2000 trv = 11 for inv = 1 (channel inversion) all bits are inverted. for motorola mode the data sections would have to have the form to yield the same output data. figure 68 0000 0000 1110 0000 1011 0101 1010 1110 1000 0001 1010 1110 1010 0010 1100 0101 10 11 change of e-, s-, x-bits itd05038 c3 86 fa xx 0 31 c0 e2 d1 xx 31 0 data 1 e, s, x 1 31 0 75 40 00 00 e, s, x 2 0 31 8a 80 00 00 xx xx 00 03 data 2
peb 20320 functional description user ? s manual 119 01.2000 v.110/x.30 receive direction general features in receive direction ? the starting sequence (00 h followed by a ? 1 ? -bit) after initialization of loss of synchronism is detected. ? the synchronization pattern is monitored, after 3 consecutive erroneous frames a loss of synchronism is detected. ? a change of e-, s-, x-bits is monitored and reported by an interrupt. ? the data bits are extracted and written into the data section. more detailed description of the individual features: 1. and 2. the receiver can be in one of 2 states: figure 69 data extraction and monitoring of a change of e-, s-, x-bits and synchronization pattern is only performed in synchronized state. in the asynchronous state the receiver waits for the synchronization patter. the ? 1 ? -bit is then interpreted as bit 1 of octet 2. 3. during the synchronized state a change of e, s, x-bits from one frame to the next and even within a frame (for sa, sb bits) is monitored. only one interrupt per frame is reported even if sa e.g. changes 3 times within the frame. the e-, s-, x-bits reported in the interrupt are s9 for sb and s8 for sa and the second occurrence of x for x. 4. the bits written into the data section are marked by o in table 2 to table 4 . as shown, bits repeated in the serial data are only strobed than at their last instance. itd05039 reset unsynchronous state synchronous state 3 consecutive erroneous frames (with a frame error) by a "1" bit 8 * "0" bit followed
peb 20320 functional description user ? s manual 120 01.2000 table 2 framing for networks with 600-bit/s data rate intermediate rate = 8 kbit/s, i.e. subchannelling with only 1 fill/mask bit set octet no.12345678 1 2 3 4 5 6 7 8 9 10 00000000 1 b1b1b1b1b1b1s1 1 b1b1b2b2b2b2x 1 b2b2b2b2b3b3s3 1 b3b3b3b3b3b3s4 1 e1e2e3e4e5e6e7 1 b4b4b4b4b4b4s6 1 b4b4b5b5b5b5x 1 b5b5b5b5b6b6s8 1 b6b6b6b6b6b6s9 table 3 framing for networks with 1200-bit/s data rate intermediate rate = 8 kbit/s, i.e. subchannelling with only 1 fill/mask bit set octet no.12345678 1 2 3 4 5 6 7 8 9 10 00000000 1 b1b1b1b1b2b2s1 1 b2b2b3b3b3b3x 1 b4b4b4b4b5b5s3 1 b5b5b6b6b6b6s4 1 e1e2e3e4e5e6e7 1 b7b7b7b7b8b8s6 1 b8b8b9b9b9b9x 1 b10 b10 b10 b10 b11 b11 s8 1 b11 b11 b12 b12 b12 b12 s9
peb 20320 functional description user ? s manual 121 01.2000 they are grouped together in the form: 31 0 1 1 b6 b5 b4 b3 b2 b1 1 1 b12 b11 b10 b9 b8 b7 1 1 b18 b17 b16 b15 b14 b13 1 1 b24 b23 b22 b21 b20 b19 (for motorola mode) 31 0 1 1 b24 b23 b22 b21 b20 b19 1 1 b18 b17 b16 b15 b14 b13 1 1 b12 b11 b10 b9 b8 b7 1 1 b6 b5 b4 b3 b2 b1 (for intel mode) where for the 600 bit/s e.g. b1 to b6 belong to the first 10-octet frame, b7 to b12 belong to the second 10-octet frame etc. table 4 framing for networks with 2400-bit/s data rate intermediate rate = 8 kbit/s, i.e. subchannelling with only 1 fill/mask bit set octet no.12345678 1 2 3 4 5 6 7 8 9 10 00000000 1 b1b1b2b2b3b3s1 1 b4b4b5b5b6b6x 1 b7b7b8b8b9b9s3 1 b10 b10 b11 b11 b12 b12 s4 1 e1e2e3e4e5e6e7 1 b13 b13 b14 b14 b15 b15 s6 1 b16 b16 b17 b17 b18 b18 x 1 b19 b19 b20 b20 b21 b21 s8 1 b22 b22 b23 b23 b24 b24 s9 table 5 framing for networks with 4800-, 9600-, 19200-, 38400-bit/s data rate intermediate rate = 8, 16, 32, 64 kbit/s, i.e. subchannelling with 1, 2, 4, 8 fill/mask bit set octet no.12345678 1 2 3 4 5 6 7 8 9 10 00000000 1 b1b2b3b4b5b6s1 1 b7b8b9b10b11b12x 1 b13 b14 b15 b16 b17 b18 s3 1 b19 b20 b21 b22 b23 b24 s4 1 e1e2e3e4e5e6e7 1 b25 b25 b27 b29 b29 b30 s6 1 b31 b32 b33 b35 b35 b36 x 1 b37 b36 b39 b41 b41 b42 s8 1 b43 b44 b45 b47 b47 b48 s9
peb 20320 functional description user ? s manual 122 01.2000 options the different options for this mode are the framing pattern as shown in table 2 to table 5 is programmed by the bits trv. interrupts the possible interrupts for this mode are frc: issued if the receiver has detected a change of s-, x-, e-bits; the value of the bits e7, ? , e1, s8 for sa and s9 for sb and the second occurrence of x within the 10- octet frame is reported within the same interrupt. (maskable by ch in the channel specification hi: issued if the hi bit is detected in the transmit descriptor (not maskable). err: issued if one of the following receive errors has occurred: ? a fast receive abort channel command was issued (this leads to a setting of the ra bit in the status byte) ? data could only partly be stored due to internal buffer overflow of rb ? 3 consecutive frames had an error in the synchronization pattern (loss of synchronism) ? the hold bit in the receive descriptor was detected (this leads to a setting of the ra bit in status in the receive descriptor). (maskable by re in the channel specification) fo: issued if due to inaccessibility of the internal buffer (rb) one or more changes of e-, s-, x-bits and/or loss of synchronism information have been lost. (maskable by re in the channel specification) example v.110/x.30 channel with cs = 0 (required) inv = 0 crc = 0 trv = 00 (600 bit/s) fa = 0 mode = 10 (v.110/x.30) motorola interface channel no. d
peb 20320 functional description user ? s manual 123 01.2000 figure 70a its08219 0000 0 0 0 0 0000 .. . 0000 0 0 0 1 10 0 0 0 111 munich32 waits for synchronization after reset 1 10 1 11 1 001 1 10 110 e9 h b3 b4 b6 b2 b1 b5 01 1 10 11 0 0 1 11 1 1 11 1 11 1 1 11 0 01 11 1 10 0 1 11 1 00 11 1 1 00 1 10 0 reported as x reported as sa reported as sb 00 0 01 1 0 0 1 1 11 00 11 10 0 1 1 11 1 11 1 1 110 00 1 0 01 1 1 10 11 1 1 1 0 0 1 1000 0 0 0 000 0 0 0 01 error in synchronization pattern b5 b1 b2 b6 b4 b3 h ca 0 1 00 11 1 0 no change of e, s, x bits 1 11 0 0 0 0 0 0 0 0 0 00 0 0 no change of e, s, x bits 1 1 10 00 d2 h b3 b4 b6 b2 b1 b5 error in synchronization pattern 1 1 11 00 11 1 11 1 110 1 1 1 1 1 1000 0 0 0 0000 0 0 0 0 1 11 1 1 11 1 1 11 1 1 11 1 1 11 1 1 11 1 1 11 1 1 11 1 1 1 11 1 1 00 0 0 0 1 0 1 1 11 1 1 1 11 1 11 10 reported as sa 0 1 b5 b1 b2 b6 b4 b3 h fa 0 11 1 11 change of e, s, x bits; but sa is still reported as ? 1 ? 0 1 1 11 1 11 0 error in synchronization pattern 0 0 00 0 1 1 1 1 1 1 1 1 0000 0 0 0 0 00 0 0 0 0 00 00 0 0 0 0 00 0 0 0 0 0 0 00 00 00 0 00 00 00 000
peb 20320 functional description user ? s manual 124 01.2000 figure 70b its08220 error in synchronization pattern 10 0 0 0000 0 0 0 0 1 00 1 11 1 11 1000 0 0 01 1 000 0 0 0 1 1 1 11 10 1000 0 0 01 11 1 1 1 1 1 1 11 1 11 1 1 1 11 1 11 1 1 1 11 1 11 1 1 1 11 1 11 1 1 1 11 1 11 1 1 1 11 1 11 1 1 1 11 1 11 1 1 1 11 1 11 1 1 1 11 1 11 0000 0 0 0 0 000 0 0 0 1 11 11 ed h 1 11 0 1 11 1 1 11 1 10 0 1 11 1 1 11 1 11 1 1 error in synchronization pattern no change of e, s, x bits change of e, s, x bits h ff 11 1 11 11 0 0 0 1 11 11 0 0 0 1 11 11 0 0 0 1 11 11 0 0 0 1 11 11 0 0 0 1 11 11 0 0 0 1 11 11 0 0 0 1 11 11 0 0 0 1 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 0000 0 0 0 0 ff h h c0 no error in synchronization pattern change of e, s, x bits change of e, s, x bits
peb 20320 functional description user ? s manual 125 01.2000 figure 71 for intel mode the data sections have the form: figure 72 itd05040 00080000 e9 ca fa d2 0 31 c0 ff ff ed 20040000 31 0 8800202d 31 0 31 0 8800022d st 1 desc 2 desc nd loss of synch. 8e5b002d 8e5b002d 8c00002d 8f57002d 8fff002d 40042000 40040000 itd05041 c0 ff ff ed 0 31 nd of 1 desc st 31 0 e9 ca fa d2 of 2 desc
peb 20320 functional description user ? s manual 126 01.2000 2.5 boundary scan unit in munich32 a test access port (tap) controller is implemented. the essential part of the tap is a finite state machine (16 states) controlling the different operational modes of the boundary scan. both, tap controller and boundary scan, meet the requirements given by the jtag standard: ieee std. 1149.1. figure 73 gives an overview. figure 73 block diagram of test access port and boundary scan test handling is performed via the pins jtest0 (tck), jtest1 (tms), jtest2 (tdi) and jtest3 (tdo). test data at jtest2 (tdi) are loaded with a 4-mhz clock signal connected to jtest0 (tck). ? 1 ? or ? 0 ? on jtest1 (tms) causes a transition from one controller state to an other; constant ? 1 ? on jtest1 (tms) leads to normal operation of the chip. if no boundary scan testing is planned jtest1 (tms) and jtest2 (tdi) do not need to be connected since pull-up transistors ensure high input levels in this case. nevertheless it would be a good practice to put the unused inputs to defined levels. in this case, if the jtag is not used: jtest1 = jtest0 = ? 1 ? . after switching on the device ( v dd = 0 to 5 v) a power-on reset is generated which forces the tap controller into test logic reset state. clock generation clock reset power on reset tap controller -finite state machine -instruction register (3 bits) -test signal generator jtest0 (tck) jtest1 (tms) jtest2 (tdi) jtest3 (tdo) clock test control data in control bus 6 id data out ss data out bs data in identification scan (32 bits) boundary scan (n bits) 1 2 n pins itb03509 enable data out test access port
peb 20320 functional description user ? s manual 127 01.2000 table 6 boundary scan sequence in peb 20320 jtest2 (tdi) pin no. pin i/o number of boundary scan cells constant value 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 reset sclk test ar tdata tsp tclk i/m b16 ready /dsack berr hlda/bg hldao/bgo bgack hold/br ads /as ds wr /rw be3 be2 d0 be1 d1 be0 d2 a2 d3 a3 d4 a4 d5 a5 d6 a6 d7 i i i i o i i i i i i i o i/o i/o o o o o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o 1 1 1 1 2 1 1 1 1 1 1 1 2 3 3 2 2 2 2 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 0 1 1 0 00 0 0 0 0 0 0 0 00 001 010 00 01 00 00 01 100 00 000 00 000 00 000 00 000 00 000 00 000 00 000
peb 20320 functional description user ? s manual 128 01.2000 table 6 boundary scan sequence in peb 20320 (cont ? d) jtest2 (tdi) pin i/o number of boundary scan cells constant value 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 a7 d8 a8 d9 a9 d10 a10 d11 a11 d12 a12 d13 a13 d14 a14 d15 a15 d16 a16 d17 a17 d18 a18 d19 a19 d20 a20 d21 a21 d22 a22 d23 a23 d24 a24 o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o i/o o 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00
peb 20320 functional description user ? s manual 129 01.2000 jtest3 (tdo) an input pin (i) uses one boundary scan cell (data in), an output pin (o) uses two cells (data out, enable) and an i/o-pin (io) uses three cells (data in, data out, enable). therefore the boundary scan of the munich32 contains a total of n = 205 scan cells. the right column of table 6 gives the initialization values of the cells. the desired test mode is selected by serially loading a 3-bit instruction code into the instruction register via jtest2 (tdi) (lsb first); see table 3. table 6 boundary scan sequence in peb 20320 (cont ? d) jtest2 (tdi) pin i/o number of boundary scan cells constant value 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 d25 a25 d26 a26 d27 a27 d28 a28/dp0 d29 a29/dp1 d30 a30/dp2 d31 a31/dp3 int/int rclk rsp rdata ci0 ci1 ci2 ci3 ci4 i/o o i/o o i/o o i/o i/o i/o i/o i/o i/o i/o i/o o i i i i i i i i 3 2 3 2 3 2 3 3 3 3 3 3 3 3 2 1 1 1 1 1 1 1 1 000 00 000 00 000 00 000 000 000 000 000 000 000 000 00 0 0 0 0 0 0 0 0
peb 20320 functional description user ? s manual 130 01.2000 extest is used to examine the interconnection of the devices on the board. in this test mode at first all input pins capture the current level on the corresponding external interconnection line, whereas all output pins are held at constant values ( ? 0 ? or ? 1 ? , according to table 6 ). then the content of the boundary scan is shifted to jtest3 (tdo). at the same time the next scan vector is loaded from jtest2 (tdi). subsequently all output pins are updated according to the new boundary scan contents and all input pins again capture the current external level afterwards, and so on. intest supports internal testing of the chip, i.e. the output pins capture the current level on the corresponding internal line whereas all input pins are held on constant values ( ? 0 ? or ? 1 ? , according to table 6 ). the resulting boundary scan vector is shifted to jtest3 (tdo). the next test vector is serially loaded via jtest2 (tdi). then all input pins are updated for the following test cycle. note: in capture ir-state the code ? 001 ? is automatically loaded into the instruction register, i.e. if intest is wanted the shift ir-state does not need to be passed. sample/preload is a test mode which provides a snap-shot of pin levels during normal operation. idcode : a 32-bit identification register is serially read out via jtest3 (tdo). it contains the version number (4 bits), the device code (16 bits) and the manufacturer code (11 bits). the lsb is fixed to ? 1 ? . idcode for old versions: 0001 for version 2.1 0010 for version 2.2 0100 for version 3.2 note: as in test logic reset state the code ? 011 ? is automatically loaded into the instruction register the id code can easily be read out in shift dr state which is reached by jtest1 (tms) = 0, 1, 0, 0. bypass : a bit entering jtest2 (tdi) is shifted to jtest3 (tdo) after one jtest0 (tck) clock cycle. table 7 boundary scan test modes instruction (bit 2 ? 0) test mode 000 001 010 011 111 others extest (external testing) intest (internal testing) sample/preload (snap-shot testing) idcode (reading id code) bypass (bypass operation) handled like bypass jtest2 (tdi) 0110 0000 0000 0000 0101 0000 1000 001 1 jtest3 (tdo)
peb 20320 operational description user ? s manual 131 01.2000 3 operational description 3.1 reset state upon reset munich32 is set to its initial state. the active high system reset clears the internal logic and causes munich32 to tristate all output lines. channel processing is deactivated. after reset all buffers are empty and no buffer size of tb is allocated to the channels. the dma controller state is set to the hold condition for all link lists. the descriptor and data pointers remain at a random value. the bits ro and to are set to ? 1 ? and ra and ta are set to ? 0 ? for all logical channels by reset. all time slots are connected to the logical channel 0 and the following configuration is set: action specification loc = loop = loopi = 0 pcm = t1/ds1 24-channel 1.536 mbit/s (000) mfl = 0 time slot assignment fill/mask = 00 h , i.e. all bits masked/set to ? 1 ? rti, tti = 0 channel number = 00 h channel specification mode = 00, i.e. tma fa = 0 iftf = 0 crc = 0 inv = 0 trv = 00, ra = 0 ta = 0 th = 0 ro = 1 to = 1
peb 20320 operational description user ? s manual 132 01.2000 transmit descriptor fnum = 00 h , i.e. shared flags in hdlc, only eight zero bits between sent frames for tmb. the e-, s-, x-bits are all set to zero internally by the reset. the receiver is set into the itf/idle state for all channels, i.e. it assumes that on the line there are ? 1 ? s as interframe time-fill for hdlc. 3.2 initialization procedure after reset munich32 remains in the initial state until the microprocessor generates an action request. in the action specification the initialization sequence is defined. the sequence can be split up into individual procedures of each channel or in one single procedure to initialize all channels at the same time. for all procedures the time slot assignment and the selected channel specifications are loaded into the csr-ram. to prevent malfunction the initialization of the link lists and the allocation of the buffer size to the channels has to be specified before the transmission can be started. the interrupt queue must be established as well. munich32 assumes that time slot 0 starts on the receive and transmit lines. they can be resynchronized by 2 rising edges of tsp and rsp respectively. the first rising edge of tsp/rsp should not take place within the first 1000 sclk clock cycles after deassertion of the reset pin. before this resynchronization the host should neither remove ro = 1, to = 1 nor set loop or loopi to ? 1 ? for any logical channel. during this time any incoming data is ignored, the transmit data line tristated. for each action service the device first reads the control start address in the control and configuration section which is located under a fixed address determined by the input signals (ci(4:0)). the values of ci(4:0) can be changed during operation. the values are used after the next falling edge of ar . ci4 is the polarity of a31 ? a22 ci3 is the polarity of a21 ? a16 ci2 is the polarity of a15 ? a4 ci1 is the polarity of a3 ci0 is the polarity of a2 a0, a1 = 0 for example ci(4:0) = 10101 address = 1111.1111.1100.0000.1111.1111.1111.0100
peb 20320 operational description user ? s manual 133 01.2000 figure 74 figure 75 ci-pin decoding 313029282726252423222120191817161514131211109876543210 ci4 ci3 ci2 ci1 ci0 00 ci4 ci3 ci2 ci1 ci0 loc. of ctrl. start addr. ci4 ci3 ci2 ci1 ci0 loc. of ctrl. start addr. 000000000000010000ffc00000 000010000000410001ffc00004 000100000000810010ffc00008 000110000000c10011ffc0000c 001000000 fff0 10100ffc0 fff0 001010000 fff4 10101ffc0 fff4 001100000 fff8 10110ffc0 fff8 001110000 fffc 10111ffc0 fffc 01000003f000011000 ffff 0000 01001003f000411001 ffff 0004 01010003f000811010 ffff 0008 01011003f000c11011 ffff 000c 01100003f fff0 11100 ffff fff0 01101003f fff4 11101 ffff fff4 01110003f fff8 11110 ffff fff8 01111003f fffc 11111 ffff fffc
peb 20320 detailed register description user ? s manual 134 01.2000 4 detailed register description 4.1 organization of the shared memory because the munich32 reads only long words, all addresses of the link lists, interrupt queue and the ccs must be a multiple of four; i.e. the two least significant bits of the address must be ? 00 ? . figure 76 depicts the organization of the shared memory for one munich32.
peb 20320 detailed register description user ? s manual 135 01.2000 figure 76 organization of the shared memory receive data channel 0 interrupt circular queue control start address action specification interrupt queue specification time slot 0 assignment channel 0 specification time slot 31 assignment channel 31 specification control and configuration section current transmit descriptor address channel 31 address channel 0 current transmit descriptor current receive descriptor address channel 31 current receive descriptor address channel 0 ccba last 8 blocks not used in t1/ds1 mode channel 0 descriptor receive channel 0 data transmit channel 0 descriptor transmit transmit descriptor channel 0 receive descriptor channel 0 itd03508
peb 20320 detailed register description user ? s manual 136 01.2000 4.2 control and configuration section 4.2.1 action specification (read once after each action request pulse) all actions are selected by setting the corresponding bits to ? 1 ? . pcm: these three bits determine the pcm highway format. 000: t1/ds1 24-channel 1.536 mbit/s 100: t1/ds1 24-channel 1.544 mbit/s 101: cept 32-channel 110: 4.096-mbit/s pcm format and even numbered time slots 111: 4.096-mbit/s pcm format and odd numbered time slots mfl: maximum frame length (up to 8191 bytes); munich32 monitors the frame length of the incoming hdlc, tmb or tmr frames. if the maximum frame length is exceeded an interrupt is generated and the current frame aborted. the length check is active in all modes except transparent mode a and v.110/x.30. therefore in all other modes one has to write a reasonable value to mfl after reset. mfl is the same for all logical channels. table 8 buffer size of the control and configuration section control and configuration section number of long words action specification 1 interrupt queue specification 2 time slot assignment 32 channel specification 128 current descriptor address 64 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 pcm 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 in ic0 0 channel number im res loc loop loopi ia 0 0 mfl
peb 20320 detailed register description user ? s manual 137 01.2000 in: initialization procedure; setting this bit to one causes munich32 to fetch all the time slot assignments and the channel specification of the selected channel (channel number). to avoid collision all time slots being reinitialized should be in a deactivated mode, i.e. the receive and transmit channels must be switched off. ico: initialize channel only; only the channel specification of the selected channel (channel number) is read and reconfigured. im: interrupt mask; munich32 suppresses the interrupt normally generated in order to acknowledge the action request. res: reset; a single initialization procedure is performed. the time slot assignment and all channel specifications are written into the csr. all time slots are reinitialized. note 1: the bits in, ico, res are mutually exclusive within one action specification. they establish different ways of initializing, configuring and reconfiguring the channels and time slots of the munich32. for test purposes four different loops can be switched at the serial interface with aid of loc, loop, loopi according to the following table loc loop loopi interpretation 000no loop 100not allowed 0 0 1 complete internal loop 1 0 1 channelwise internal loop 0 1 0 complete external loop 1 1 0 channelwise external loop 011not allowed 111not allowed the loops have the following functions: ? complete external loop the serial data input is physically mirrored back to the serial data output. the time and strobe signals for receive and transmit direction have to be identical. ? complete internal loop the serial data output is physically mirrored back to the serial data input. the data on the external input line are ignored. the logical channels have to be programmed identically. the time and strobe signals for receive and transmit direction have to be identical.
peb 20320 detailed register description user ? s manual 138 01.2000 ? channelwise external loop one single logical channel is mirrored logically from serial data input to serial data output. the other channels are not affected by this operation. the data rate for this single logical channel has to be identical for receive and transmit direction. ? channelwise internal loop one single logical channel is mirrored logically from serial data output to serial data input. the other channels are not affected by this operation. the data rate for this single logical channel has to be the same for receive and transmit direction. see chapter 5.1 and chapter 5.3.2 for a more detailed discussion of test loops. all loops of the munich32 v3.2 are under complete software control. loops can be closed and opened via software. handling of the munich32 v3.2 loops: switch loops on: res = in = ico = ? 0 ? loc, loop, loopi for selected loop type pcm, mfl, im, ia don ? t change the previous values channel number in case of channelwise loops use the selected channel number in case of complete loops use channel number of an active channel. switch loops off: res = in = ico = ? 0 ? loc = ? 0 ? , loop = loopi = ? 1 ? pcm, mfl, im, ia don ? t change the previous values channel number use channel number used with the ? switch loop on ? . ia: interrupt attention; a new interrupt queue is defined by the host. munich32 reads the interrupt queue specification and writes the interrupt information into the new interrupt queue.
peb 20320 detailed register description user ? s manual 139 01.2000 figure 77 action specification its08221 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 pcm in ico loc channel number 0 43210 00 res im loop loopi ia mfl maximum frame length maximum size of a received frame in hdlc, tmb and tmr mode (up to 8192 bytes). a received frame is aborted and an interrupt is generated if the size of a received frame exceeds the mfl value. mfl applies to all channels. pcm highway format 0 0 0 0 0 1 0 1 0 0 1 1 1 0 0 1 0 1 1 1 0 1 1 1 not allowed t1/ds1 24 time-slots, 1.536 mbit/s channel no. used in conjunction with in initialize channel only only the channel spec. (channel number) is read and reconfigured. initialization procedure read the complete time-slot assignment and the channel spec. of the specified channel (channel number). interrupt attention a new interrupt queue has been defined. read the interrupt queue specification. no loop complete internal loop channelwise int. loop channelwise ext. loop 1 1 1 1 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 0 1 0 0 0 loops complete internal loop read the complete time-slot assignment read all channel specifications reinitialize all time-slots reset do not generate the arack & arf interrupt interrupt mask and ico of the selected channel not allowed not allowed cept 32 time-slots, 2.048 mbit/s 4.096 mbit/s pcm format, even time-slots 4.096 mbit/s pcm format, odd time-slots not allowed not allowed not allowed t1/ds1 24 time-slots, 1.544 mbit/s
peb 20320 detailed register description user ? s manual 140 01.2000 4.2.2 interrupt queue specification the interrupt queue is specified as a kind of block (queue), starting on a start address (programmable) with a defined length (programmable). both, the start address and the queue length are programmable in the interrupt queue specification of the control and configuration section. figure 78 the minimum queue size is 16 long words; the maximum queue size is 4096 long words. for each interrupt arising, the munich32 writes the interrupt information into the interrupt queue, will increment the pointer to the next address in this block automatically and will generate an interrupt pulse at each interrupt occasion. it is up to the processor to read the interrupt informations out of the interrupt queue. if the munich32 arrives at the end of the interrupt queue, it will jump to the start address of the interrupt block again (cyclic queue) and completely overwrite the previous information. therefore the length of the interrupt queue should be calculated so, that the munich32 will not overwrite information which was not yet read by the processor. 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 interrupt queue address 0000000000000000 1514131211109876543210 interrupt queue address 00000000 n start address (interrupt queue address) length = (n + 1) 16 long words where 0 n 255 overwrite . . . interrupt information long word 1 interrupt information long word 2 interrupt information long word 3 interrupt information long word (n+1)x16
peb 20320 detailed register description user ? s manual 141 01.2000 4.2.3 interrupt information the next table shows the bit assignments for the interrupt information long word. when an interrupt occurs munich32 sets the int bit and writes the interrupt information and the channel number into the interrupt circular buffer. at the same time it generates an interrupt pulse. the classes of error (for example host initiated interrupt or crc error) of a channel in one direction are treated independently of each other. if several interrupt events coincide they will be indicated to the host with one shared interrupt. bit assignment for interrupt queue there are 3 classes of bits in the interrupt: 1. bits present in each interrupt: int: this bit is always set to ? 1 ? vn(3:1): these bits are ? 000 ? for version 1.1 ? 001 ? for version 2.1 ? 010 ? for version 2.2 ? 100 ? for version 3.2 ? 110 ? for version 3.4 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 int 0 interrupt information 1514131211109876543210 interrupt information channel number/direction 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 int 0 vn3 vn2 vn1 frc e7 e6 e5 e4 e3 e2 e1 sb sa x 15 1413121110 9 876543210 arack arf hi fi ifc sf err fo 0 0 rt channel number
peb 20320 detailed register description user ? s manual 142 01.2000 2. action request interrupts arack: action request acknowledge; munich32 sets the arack bit to indicate that an action request has been serviced. arf: action request fail; munich32 aborts an action request, if the required configuration cannot be performed. an action request fail can occur either when the tb buffer is initialized incorrectly or a bus cycle error (berr = 0) is detected during a configuration access. if arack or arf is set, all bits except int and vn(3:1) are set to 0. note: an action request is forbidden during the time a preceding action has not been finished by an arack or arf interrupt or a pulse at the reset pin. 3. channel specific interrupts these interrupts indicate specific events in the channel indicated by ? channel number ? and receive or transmit direction indicated by rt (rt = ? 1 ? : receive direction; rt = ? 1 ? : transmit direction). the interpretation of these interrupts depends on the specification of the channel in which they occur. the following table shows which interrupts can occur in which mode (unused bits are always 0). hdlc 1 0fff0 0 000 000000 v.110/x.30 1 0f ff r r rrr rrrrrr tma 1 0fff0 0 000 000000 tmb/tmr 1 0fff0 0 000 000000 hdlc g gtrtrrr trtr00 xxxxxx v.110/x.30 g gtr00 0 trtr00 xxxxxx tma g gtrt0 0 trtr00 xxxxxx tmb/tmr g gtrtr0 0 trtr00 xxxxxx 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 int 0 vn3 vn2 vn1 frc e7 e6 e5 e4 e3 e2 e1 sb sa x 15 14 13121110 9 8765 43210 arack arf hi fi ifc sf err fo 0 0 rt channel number
peb 20320 detailed register description user ? s manual 143 01.2000 where ? 1 ? means that the bit is always ? 1 ? for this mode ? 0 ? means that the bit is always ? 0 ? for this mode ? f ? means the bit is fixed by the version number ? r ? means a bit that can only be set in the receive direction, i.e. may only be ? 1 ? if rt is ? 1 ? ? t ? means a bit that can only occur in transmit direction, i.e. may only be ? 1 ? if rt is ? 0 ? ? tr ? means a bit that can occur in receive or transmit direction ? g ? means a bit of an activation request interrupt which cannot be ? g ? in a channel specific interrupt ? x ? means a bit fixed by the channel and direction (receive, transmit) of the event it belongs to. the meaning of the interrupt bits depend on the mode. we therefore will discuss them bit for bit and indicate the different meanings in the different modes. frc: (v.110/x.30 mode, receive direction only) change of the framing (e, s, x) bits of the v.110/x.30 frame detected. this interrupt is generated whenever a change in the e-, s-, x-bits is detected, but at most one time within one frame of 10 octets, even if there is more than one change within the frame. after detecting a receive abort channel command for one 10-octet frame frc is also issued. ex, sx, x: (v.110/x.30 mode, receive direction only, only in conjunction with frc) the value of the bits ex, sx, x in the received v.110/x.30 frame. if a value changes, e.g. 2 times within the same frame only the final change is reported. if the change was caused by a receive abort channel command all bits are 0. hi: (all modes, all direction) host initiated interrupt; this bit is set when the munich32 detects the hi bit in the receive or transmit descriptor and branches to the next descriptor, or starts polling the hold bit if set. fi: 1.1 hdlc, tmb, tmr receive direction: fi = 1 indicates, that a frame has been received completely or was stopped by a receive abort channel command or fast receive abort or a hold in a receive descriptor. it is set when the munich32 branches from the last descriptor belonging to the frame to the first descriptor of a new frame. it is also set when the descriptor in which the frame finished contained a hold bit, the interrupt is then issued when the munich32 starts polling the hold bit. 1.2 hdlc, tmb, tmr, tma transmit direction: issued if the fe bit is detected in the transmit descriptor. it is set when the munich32 branches to the next transmit descriptor, belonging to a
peb 20320 detailed register description user ? s manual 144 01.2000 new frame, or when it starts polling the hold bit if set in conjunction with the fe bit; err and fi are set if a transmit descriptor contains a hold bit no fe bit ifc: (hdlc mode, receive direction only) idle/flag change; an interrupt is generated in hdlc if the device changes the interframe time-fill (itf) state. after reset the device is in the itf idle state. it changes to the itf flag state if it receives 2 consecutive flags with or without shared zeroes. it changes back to the itf idle state upon reception of 15 contiguous ? 1 ? -bits or when a receive abort channel command is active during 15 received bits. sf: (hdlc mode, receive direction only, always in conjunction with fi) short frame detected a frame with 16 bits between start flag and end flag or end abort flag for crc16 32 bits between start flag and end flag or end abort flag for crc32 has been detected. the sequences 7e 7f h and 7e fe h and 7e ff h are also short frames. sf is always in conjunction with err except for the frames 7e00 007e h for crc16 7e00 0000 007e h for crc32 err: always in conjunction with fi = 1 1.1 hdlc mode receive direction one of the following receive errors occurred ? fcs of the frame was incorrect ? the bit length of the frame was not divisible by 8 ? the byte length exceeded mfl ? the frame was stopped by 7f h ? the frame could only be partly stored due to internal buffer overflow of rb ? the frame was ended by a receive abort channel command ? the frame could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the frame. ? the frame was aborted by a fast receive abort channel command a more detailed error analysis can be done by the status information in the receive descriptor. 1.2 hdlc mode transmit direction one of the following transmit errors occurred: ? the last descriptor had hold = 1 and fe = 0 ? the last descriptor had no = 0 and fe = 0
peb 20320 detailed register description user ? s manual 145 01.2000 2.1 v.110/x.30 mode receive direction one of the following receive errors occurred: ? data could only partly stored due to internal buffer overflow of rb ? 3 consecutive frames had an error in the synchronization pattern (loss of synchronism) ? a fast receive abort channel command was issued ? the data could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the data ? a receive abort channel command was active for at least 3 consecutive frames a more detailed error analysis can be done by the status information in the receive descriptor. 2.2 v.110/x.30 mode transmit direction one of the following transmit errors occurred ? the last descriptor had a hold = 1 or fe = 1 ? the last descriptor had fe = 0 and no = 0 3.1 tma mode receive direction one of the following errors occurred ? the data could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the data ? a fast receive abort channel command was issued 3.2 tma mode transmit direction see chapter 1.2 4.1 tmb/tmr mode receive direction always in conjunction with fi = 1 one of the following receive errors occurred ? the bit length of the frame was not divisible by 8 ? the frame could only be partly stored due to internal buffer overflow of rb ? the frame could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the frame ? the frame was aborted by a fast receive abort channel command a more detailed error analysis can be done by the status information in the receive descriptor. 4.2 tmb/tmr mode transmit direction see 1.2 fo: 1.1 hdlc, tmb, tmr receive direction the munich32 has discarded one or more whole frames or short
peb 20320 detailed register description user ? s manual 146 01.2000 frames or change of interframe time-fill informations due to inaccessibility of the internal buffer rb. 1.2 hdlc, tmb, tmr transmit direction the munich32 is unable to access the shared memory in time or has detected a bus cycle error (berr = 0) during a read access on the transmit data section. the current erroneous frame is aborted with a ? 0 ? and 14 ? 1 ? for hdlc, with 00 for tmb and 0000 for tmr; afterwards interframe time fill is sent until the munich32 can access again the shared memory. the munich32 will read the transmit data from the location which should be accessed before the tx-fo or berr happened and transmit the rest of the erroneous frame. 2.1 v.110/x.30 receive direction the munich32 has discarded a loss of synchronism information or a change of a e-, s-, x-bits information due to inaccessibility of the internal buffer rb. 2.2 v.110/x.30 transmit direction the munich32 is unable to access the shared memory in time or has detected a bus cycle error (berr = 0) during a read access on the transmit data section. it generates 3 10-octet frames with framing errors and restarts with the next error-free transmit data. 3.1 tma receive direction the munich32 has discarded data due to inaccessibility of the internal buffer rb. 3.2 see chapter 1.2 the following table shows which interrupt bits are masked by which bits in the channel specification. receive ch transmit ? receive fir ifc sfe re re transmit fit ?? te te 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 int ? vn3 vn2 vn1 frc e7 e6 e5 e4 e3 e2 e1 sb sa x 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 arack arf hi fi ifc sf err fo 0 0 rt channel number
peb 20320 detailed register description user ? s manual 147 01.2000 general im im figure 79 interrupt information its08222 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 int 0 vn(3...1) frc e7 e6 e5 e4 e3 e2 e1 sb sa x arack arf hi fi ifc sf err f0 00 rt channel number framing bits changed v.110/x30 mode received e, s, x bits changed action request acknowledge action request has been completed successfully. action request failed action request could not be host initiated interrupt hi bit in the rcv./xmt. descriptor was set end of receive or transmit frame indication frame indication interframe timefill change hdlc receiver detected change in itf state short frame (empty hdlc frame or incorrect hdlc frame, hdlc mode, in conjunction with fi protocol error e.g. crc error, frame aborted, loss of sync. mfl exceeded internal buffer overflow/underflow overflow/underflow internal buffer not available direction 0 transmit interrupt 1 receive interrupt channel number identifies the channel where the interrupt occured. 3210 silicon version number 0 0 0 v1.1 v2.1 0 0 1 0 1 0 v2.2 valid interrupt entry munich32 sets this bit with every entry to the interrupt circular queue software should dear this bit after reading v3.2 1 0 0 completed successfully. nothing stored in memory)
peb 20320 detailed register description user ? s manual 148 01.2000 4.2.4 time slot assignment (read only once after each action request pulse with an action specification with set in or res bit) the time slot assignment provides the cross reference between the 32 (24) time slots of the pcm highway and the data channels (up to a maximum number of 32). the data channels can be composed of different receive and transmit time slots, which have individual bit rates. with the concept of subchanneling, munich32 can realize flexible transmission from 8 kbit/s up to 2.048 mbit/s per channel. fill/mask code: for bit rate adaption the fill/mask code determines the number of bits and the position of these bits within the time slot. for all modes except tma the bits selected by fill/mask = 1 in the slots of a channel are concatenated, those with fill/mask = 0 are ignored/tristated in receive/transmit direction. for tma the bits with fill/mask = 0 are received as ? 1 ? -bits, in transmit direction these bits are overwritten with ? z ? (see chapter 2.4 for more details). 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 0 0 tti transmit channel number transmit fill mask time slot 0 0 0 tti transmit channel number transmit fill mask time slot 1 0 0 tti transmit channel number transmit fill mask time slot 31 1514131211109876543210 0 0 rti receive channel number receive fill mask time slot 0 0 0 rti receive channel number receive fill mask time slot 1 0 0 rti receive channel number receive fill mask time slot 31
peb 20320 detailed register description user ? s manual 149 01.2000 channel number: the channel number identifies the data channel. its transmission mode is described in the respective channel specification. tti: transmit time slot inhibit; setting this bit to ? 1 ? causes munich32 to tristate the transmit time slot. the data is not destroyed but sent in the next not tristated time slot allocated to this channel. rti: receive time slot inhibit; setting this bit to ? 1 ? causes munich32 to ignore the received data in the time slot. the channel is not processed in this time slot. 4.2.5 channel specification (read only once after each activation request pulse with an action specification with set in, res or ico bit; res: the channel specifications of all channels; in, ic0: the channel specification of the channel indicated in the action specification) interrupt mask: these bits mask the bits in the interrupt information long word according to the table at the end of chapter 4.2.3 (interrupt information). 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 interrupt mask nitbs ri ti to ta th ro ra frda ftda 00000000 0 0000000 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 tflag tflag /nsf tflag /cs inv cr c trv fa mode ift f frda ftda 000000 0 0 0 0 itbs 76543210 ? sfe ifc ch te re fir fit
peb 20320 detailed register description user ? s manual 150 01.2000 if an event leads to an interrupt with several bits set (e.g. fi and err) masking only a proper subset of them (e.g. err) will lead to an interrupt with the nonmasked bits set (e.g. fi). if all bits of an event are masked, the interrupt is suppressed. the interrupt mask is therefore bit specific and not event specific. nitbs: new itbs value; if this bit is set the individual transmit buffer size itbs is valid and a new buffer field of tb is assigned to the channel. in this process first the occupied buffer locations of the channel are released and then according to itbs a new buffer area is allocated. if there is not enough buffer size in tb (occupied by other channels) the process will be aborted and an action request failure interrupt is generated. after aborting no buffer size is allocated to the channel. for preventing action request failure enough buffer locations must be available. this can be done by reducing the buffer size of the other channels. to avoid transmission errors all channels to be newly configured must be deactivated before processing. note: itbs has to be set to ? 0 ? if nitbs = ? 0 ? . nitbs should be set to ? 0 ? in conjunction with a transmit abort channel command. the bits ri, ti, to, ta, th, ro, ra are the so called channel command bits. they allow the channel to be initialized, aborted or reconfigured at the serial side as well as at the p side. these bits can be decomposed in 3 independent command groups: ri, ro, ra form the receive command group to, ti, ta the first transmit command group and th is the second transmit command group. we will discuss these bits according to the groups. 1. receive command group (6 commands) ? receive clear ri = 0, ro = 0, ra = 0 (clears a previous receive abort or receive off condition, affects only the serial interface) the effect of this command depends on the previous history of the channel if the channel was never initialized by a receive initialization command it has no effect if it was initialized previously it clears a receive off or receive abort condition set by a previous channel command if no receive off or receive abort condition is set it has no effect. ? fast receive abort ri = 0, ro = 0, ra = 1 (clears a previous receive abort or receive off condition, affects only the dma interface) this abort is performed in the dma controller and does not interfere with the reception on the serial interface and the transfer of the data into the receive buffer. if this abort is detected the current receive descriptor is suspended with an abort status (ra bit set
peb 20320 detailed register description user ? s manual 151 01.2000 to ? 1 ? ) followed by a branching to the new descriptor (frda) defined in the channel specification of the ccs. for hdlc, tmb, tmr the rest of a frame which was only partially transferred before suspension of the receive descriptor is aborted, the new descriptor is related to the next frame. an interrupt with fi, err is issued. for v.110/x.30 and tma data bits might get lost. an interrupt with err is issued. ? receive off ri = 0, ro = 1, ra = 0 (clears a previous receive abort condition, sets off condition, affects only the serial interface) this channel command sets the receiver into the receive off condition. the receive channel is disabled completely at the serial interface, i.e. the receive deformatter rd is reset and the receive buffer rb is not accessed for this channel. a currently processed frame (hdlc, tmb, tmr mode) is not properly finished with any status information. the data stored in the rb at that time is still transferred to the shared memory. after the receive off condition is cleared by another channel command: in hdlc, tmb, tmr (v.110/x.30, tma) mode the device waits for a new frame (10- octet frame, nothing) to begin and then starts filling rb again. if the receive off command lead to an improper finishing of a frame (data, data), the new frame (data, data) is concatenated with the finished one. to avoid this problem there are two suggestions: a) issue a receive abort channel command and wait for 32 (240, 8) bits for this channel to be processed before issuing the receive off command. b) wait in the receive off condition until the rb is emptied for this channel (i.e. for at most 8 pcm frames if the munich32 has sufficient access to the shared memory) and leave the receive off condition by a receive initialization command. the receive off channel command is ignored in case of any kind of loop. ? receive abort ri = 0, ro = 1, ra = 1 (clears a previous receive off condition, sets a receive abort condition, affects only the serial interface) this receive channel command sets the receiver into the receive abort condition. in this condition it receives (instead of the normally received bits) logical ? 1 ? bits for hdlc logical ? 0 ? bits for v.110/x.30, tmb, tmr logical ? 0 ? bits for unmasked bits in tma mode logical ? 1 ? bits for masked bits in tma mode irrespective of the inv bit. this leads to for hdlc: a currently processed frame is aborted after 7 received bits for this channel, leading to a ra set in the status of the frame and an interrupt with set fi and err bits only or to an interrupt with set sf, fi and err bits. if the receiver was
peb 20320 detailed register description user ? s manual 152 01.2000 in the flag interframe time-fill state it will lead to an interrupt with set ifc bit after 15 received bits. for v.110/x.30: if the receiver was in the synchronized frame state it will go to the unsynchronized state after 240 bits and issue a loss bit in the status of the current receive descriptor. it will also issue an interrupt with set err bit and (unless all e-, s-, x-bits were 0 previously) issue one or two interrupts with frc set and having all e-, s-, x-bits at 0 in the last one. for tmb: a currently processed frame is aborted after 15 received bits for this channel, leading to an interrupt with fi set but err on 0, the status of this frame is always 00 h . for tmr: a currently processed frame is aborted after 31 received bits for this channel, leading to an interrupt with fi set but err on 0, the status of this frame is always 00 h . for tma: the device receives the inverse of the fill/mask bits programmed for this channels. note 1: it is advisable to clear the receive abort condition via a receive off command for v.110/x.30 mode, the tmb and the tmr mode. 2. after issuing a receive abort channel command it is advisable to stay in this condition during at least 16, 240, 16, 32, 8 bits of the channel for hdlc, v.110/ x.30, tmb, tmr, tma respectively. ? receive jump ri = 1, ro = 0, ra = 0 (clears a previous receive abort or receive off condition, affects only the dma interface) during normal operation branching to a new descriptor (frda) is possible without interrupting the current descriptor and aborting the received frame (hdlc, tmb, tmr) or received data (v.110/x.30, tma). the dma controller will proceed finishing the current receive descriptor as usual either with a frame end condition or with the corresponding data buffer completely filled and afterwards branch to the new descriptor specified by frda. thus a received frame may be splitted on ? old ? and ? new ? descriptors. ? receive initialization ri = 1, ro = 0, ra = 1 (clears a previous receive abort or receive off condition, affects the dma and serial interface) before the munich32 has got a receive initialization command it will not receive anything properly in a channel. this command should therefore be the first channel command after a pulse at the reset pin for a channel to be used. frda is then the address of the starting point of the receive descriptor chaining list. if the command is issued during normal operation it only affects the dma interface. the current receive descriptor is suspended without writing the second long word with the status, no interrupt is generated. for hdlc, tmb, tmr the rest of a frame which was only partially transferred before the suspension of the receive descriptor is
peb 20320 detailed register description user ? s manual 153 01.2000 aborted, the new descriptor (frda) is related to the next frame. for v.110/x.30 and tma data bits might get lost. general notes to receive commands: 1. after a pulse at the reset pin a channel having a time slot with rti = 0 should be issued receive off commands until it is supposed to be used. 2. when it is supposed to be used it should be issued a receive initialize command before using any other receive channel command. 3. to shut down a channel in receive direction one should first set it into the receive abort condition for the time specified there and then set it into the receive off condition. 4. before changing the mode, crc, cs, trv, inv, tflag bits of a channel or its rti or time slot assignment or its fill/mask bits it should have been shut down. the bits should be changed while issuing the receive off command. 5. to revive a channel after it has been shut down one should use the receive initialization command. 6. to switch to a new starting point of a receive descriptor chain one should preferably use the receive jump command, only exceptionally the fast receive abort command and never the receive initialize command. 7. to issue channel commands not affecting the receive side one should issue ? a receive clear command if neither a receive off nor a receive abort condition is set ? a receive off command if a receive off condition is set ? a receive abort command if a receive abort condition is set. 8. combinations of the bits ri, ro, ra not in this description are reserved and are not allowed to be used. 2. first transmit command group ? transmit clear ti = 0, to = 0, ta = 0 (clears a previous transmit abort or transmit off condition, affects only the serial interface) if the channel was never initialized by a transmit initialization command it has no effect if it was initialized previously it clears a transmit off or transmit abort condition set by a previous channel command if no transmit off or transmit abort condition is set it has no effect ? fast transmit abort ti = 0, to = 0, ta = 1 (clears a previous transmit abort or transmit off condition, affects only the dma interface) this abort is performed in the dma controller and does not interfere with the current transmission on the serial interface and the transfer between the tf and tb. if this abort is detected the current descriptor is suspended and the frame or data transferred to the tb is aborted. the next frame beginning in the transmit descriptor (ftda) defined in the channel specification of the ccs will be started immediately.
peb 20320 detailed register description user ? s manual 154 01.2000 for hdlc, tmb, tmr the first part of the frame of the suspended descriptor is sent and append by 011 1111 1111 111 for hdlc at least 00 h for tmb at least 00 00 h for tmr afterwards the next frame is started. for v.110/x.30 three 10-octet frames with errors in the synchronization pattern are sent after the data of the suspended descriptor, afterward the next data are sent in correct frames. for tma a tflag (fa = 1) or ff h (fa = 0) is sent in at least one time slot after the data of the suspended descriptor, afterwards the next data are sent. ? transmit off ti = 0, to = 1, ta = 0 (clears a previous transmit abort condition, sets a transmit off condition, effects only the serial interface) the transmit channel is disabled immediately, i.e. the transmit formatter is reset and the transmit buffer is not accessed for this channel. the output time slots are tristated. upon leaving the transmit off mode the transmit link list must be initialized by a transmit reinitialize command. otherwise the transmission will be started with the remaining data still stored in tb and continue with the old link list. if a loop condition is set the transmit off does not reset the transmit formatter, it only tristates the serial output line. after the transmit off condition is cleared by the transmit initialize command. in hdlc, tmb, tmr, v.110/x.30 the device starts with the interframe time-fill 7e for hdlc and iftf = 0 ff for hdlc and iftf = 1 00 for tmb, tmr, v.110/x.30 and then with the frame in the descriptor at ftda. for v.110/x.30 this descriptor must have the v.110-bit set and point to the e-, s-, x-bits, the data are then at the next transmit descriptor. in tma mode the device starts with the interframe time-fill tflag for fa = 1 ff h for fa = 0 and then with the data in the descriptor at the ftda.
peb 20320 detailed register description user ? s manual 155 01.2000 ? transmit abort ti = 0, to = 1, ta = 1 (clears receive off condition, sets transmit abort condition, affects only the serial interface) this abort is performed in the transmit formatter at the serial interface. the currently transmitted frame is aborted by 011 1111 1111 1111 for hdlc 00 h for tmb 0000 h for tmr 3 frames with erroneous synchronization pattern for v.110/x.30 tflag for tma, fa = 1 ff for tma, fa = 0. afterwards or ? if no frame is currently sent directly inter frame time fill: 7e for hdlc and iftf = 0 ff for hdlc and iftf = 1 00 for tmb, tmr, v.110/x.30 tflag for tma, fa = 1 ff for tma, fa = 0 is sent. during transmit abort the tf does not access the transmit buffer. the handling of the link list is not affected by the transmit abort, i.e. the device keeps the tb full. when the transmit abort is withdrawn the transmit formatter continues the transmission with the data stored in tb. in the case of hdlc or tmb or tmr mode the remaining data of the aborted hdlc or tmb frame is sent as a new independent frame. to avoid this problem the link list must be reinitialized by a transmit initialization command together with the revoking of the transmission abort. another proper use of the transmit abort command consists in setting the last descriptor of the last frame to be transmitted with hold = 1 and waiting for the device to poll the hold bit (itbs + 2) times where itbs is the number of long words assigned to this channel currently. afterwards tb is empty and the transmit abort then issued does not abort a currently sent frame. the same procedure can also be used for the transmit off command. ? transmit jump ti = 1, to = 0, ta = 0 (clears a transmit off and transmit abort condition, affects only the dma interface) this bit is set only during normal operation. then munich32 branches to the transmit descriptor (ftda) specified in the ccs after finishing the current transmit descriptor without interrupting or aborting the transmitted frame. the dma controller will proceed finishing the current transmit descriptor as usual and afterwards branch to the new descriptor specified by ftda. if the current descriptor does not include a frame end (fe = 0) (hdlc, tmb, tmr) the dma controller will link the following data section(s) of the ? new ? descriptor chain to the opened frame. this may generate unexpected frames.
peb 20320 detailed register description user ? s manual 156 01.2000 ? transmit initialization ti = 1, to = 0, ta = 1 (clears a previous transmit abort condition, affects the dma interface and the serial interface) before the munich32 has got a transmit initialization command it will not transmit anything properly in the channel. this command should therefore be the first channel command after a pulse at the reset pin for a channel to be used. ftda is then the address of the starting point of the transmit descriptor for chaining list. in this case the transmit initialize command should be accompanied by the nitbs bit set and a reasonable value for itbs (0 < itbs < 64). if the command is issued during normal operation it only affects the dma. the munich32 stops processing of the current link list and branches to the transmit descriptor at the ftda address. the data stored in the tb are discarded and the tb is filled with the data of the new descriptor. 3. second transmit command group ? transmit hold th; setting this bit causes the device to finish transmission of the current frame (hdlc, tmb, tmr mode) the current data (tma -mode) or leads to an abort with 3frames with ? 0 ? -bits (v.110/x.30-mode). afterwards for hdlc mode and iftf = 1 ff h fill characters hdlc mode and iftf = 0 7e h fill characters v.110/x.30-mode 00 h fill characters tma mode and fa = 1 tflag fill characters tma mode and fa = 0 ff h fill characters tmb/tmr 00 h fill characters are sent until th is withdrawn by a further action specification affecting the channel specification of this channel. afterwards no further access to the tb from tf is done, therefore no further data are fetched from the shared memory and the polling of a possible hold bit in the transmit descriptor stops. to send necessary frames/data before the transmit hold is active one should use the proper procedure described under the transmit abort command. general notes to transmit commands: 1. after a pulse at the reset pin a channel having a time slot with tti = 0 should be issued transmit off commands and th = 1 until it is supposed to be used. 2. when it is supposed to be used it should be issued a transmit initialization command and th = 0 before using any other transmit channel commands (together with nitbs = 1, itbs 0). 3. to shut down a channel in transmit direction one should first set it into the transmit abort condition or use the th bit with the proper procedure. one should leave it in
peb 20320 detailed register description user ? s manual 157 01.2000 that condition for 32, 240, 32, 32, 8 bits for hdlc, v.110/x.30,tmb, tmr, tma respectively and then set it into the transmit off condition. 4. before changing the mode, crc, cs, trv, inv, tflag bits or tti or time slot assignment or the fill/mask bits or the itbs the channel should be shut down. the bits should be changed while issuing the transmit off command. 5. to revive a channel after it has been shut down one should use the transmit initialization command. 6. for v.110/x.30-mode the first descriptor after reviving from shut down or initialization after reset must have the v.110-bit set and contain the e-, s-, x-bits. 7. to switch to a new starting point of a transmit descriptor chain one should preferably use the transmit jump command, only exceptionally the fast transmit abort command and never the transmit initialize command. 8. to issue channel commands not affecting the transmit side one should issue ? th with the last set value ? a transmit clear command if neither a transmit off nor a transmit abort condition is set ? a transmit off if a transmit off condition is set ? a transmit abort if a transmit abort condition is set. 9. bit combinations in the first transmit command group not described are reserved. 10. set nitbs = 1 preferably in conjunction with a transmit initialize and transmit clear command if tb is to be newly configured, otherwise set nitbs = 0. tflag: transparent mode flag; these bits are only used in the transparent mode a and constitute the fill code for flag stuffing and for flag filtering. these bits must be set to ? 0 ? if subchanneling is used in transparent mode a. bit no. 15 is the first bit of the flag to be received/transmitted. nsf: no short frame suppression; nsf = 1 is only allowed in combination with hdlc mode and cs = 1. in this mode the munich32 transfers all data to the shared memory even if only one byte (or more) per ? frame ? is received. no short frame interrupt and no short frame status bit will be generated in this case. note:crc is still calculated and checked and e.g. a frame of 1 or 2 byte length (in crc16 mode) will always cause an fi + err interrupt.
peb 20320 detailed register description user ? s manual 158 01.2000 receive frame examples: a) 0x7e, data byte, 0x7e ? data byte copied to shared memory + frame end ? status sf-bit set ? no sf indication interrupt generated ? fi indication interrupt generated ? err interrupt generated due to wrong crc ? b) 0x7e, data byte = 0xfc (or 0xfd or 0x7f), 0x7e ? no data byte copied to shared memory ? sf and fi interrupt generated cs: crc select; only used in hdlc mode. setting this bit to ? 1 ? causes the munich32 to transfer the crc bits to the data section in the shared memory. in receive direction the crc check is carried out whereas in transmit direction the crc generation is suppressed, see chapter 2.4 for more details. inv: inversion; if this bit is set, all data of the channel transmitted or received by the munich32 is inverted. crc: cyclic redundancy check; in hdlc mode this bit determines the crc generator polynomial: when the crc bit is set to ? 1 ? the 32-bit crc is performed, otherwise the 16-bit crc; for tmb/tmr mode this bit distinguishes: tmb: crc = ? 0 ? tmr: crc = ? 1 ? for all other modes this bit has to be set to ? 0 ? .
peb 20320 detailed register description user ? s manual 159 01.2000 trv: transmission rate of v.110/x.30. these signals determine the number of repeated d-bits in a v.110/x.30 frame. note: in the other modes these bits must be set to ? 00 ? . fa: flag adjustment selected (in hdlc mode) or flag filtering (selected in transparent mode a only if all fill/mask bits of the corresponding slots are ? 1 ? ). in all other modes this bit must be set to ? 0 ? . if flag adjustment is selected in hdlc mode the number of interframe time-fill characters is fnum minus one eighth of the number of zero insertions in the frame proceeding the interframe time-fill and belonging to the same transmit descriptor as fnum. if flag filtering is selected and fills a physical time slot in transparent mode a the flag specified in tflag is recognized and extracted from the data stream. in transmit direction the flag tflag is sent in all exception conditions, i.e. abort, idle state etc.; if flag filtering is not selected ? 1 ? -bits are sent in this case. flag filtering is only allowed if all fill/mask codes are set to ? 1 ? , i.e. subchanneling is not allowed. if flag filtering is not selected the bits in tflag have to be set to 0 for tma. mode: defines the transmission mode: 11: hdlc mode 10: v.110/x.30 mode 00: transparent mode a 01: transparent mode b or transparent mode r. iftf: interframe time-fill: this bit determines the interframe time-fill for hdlc mode: iftf = 0:ae h characters are sent as interframe time-fill iftf = 1:ff h characters are sent as interframe time-fill. frda: first receive descriptor address points to the beginning of the receive data chaining list. this descriptor is only interpreted with a fast receive abort or a receive jump or a receive initialization command. it is read but ignored with any other receive channel command. table 9 trv no. of repetitions transmission rate 00 01 10 11 7 3 1 0 600 bit/s 1200 bit/s 2400 bit/s 4.8, 9.6, 19.2, 38.4 kbit/s
peb 20320 detailed register description user ? s manual 160 01.2000 ftda: first transmit descriptor address points to the beginning of the transmit data chaining list. this descriptor is only interpreted with a fast transmit abort or a transmit jump or a transmit initialization command. it is read but ignored with any other transmit channel command. itbs: individual transmit buffer size; for undisturbed transmission an on-chip transmit buffer with a total size of 64 long words stores the data before formatting and transmitting. the individual buffer size specifies the part of the on chip transmit buffer allocated to the channel. this allows a variable data buffer size if nitbs = 0, itbs has to be set to 0 also; it is then read but ignored. (see chapter 2.3 ). figure 80 channel specification its08223 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 frda (first receive descriptor address) ftda (first transmit descriptor address) 0 tflag trv mode 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 sfe ifc ch te re fir fit nitbs ri ti to ta th ro ra iftf fa crc inv cs interrupt mask new itbs value new xmt. buffer size (itbs valid) rcv./xmt. rcv. commands (ri, ro, ra): 000 rcv. clear rcv. off 010 rcv. abort 011 rcv. jump 100 rcv. init. 101 not allowed 110 not allowed 111 first xmt. commands (ti, to, ta): ifc: ch: te: re: fir: fit: (r) (t) transmitter interrupt receiver interrupt idle/flag change (r) v.110 frg. chg. (r) err interrupt (t) err interrupt (r) fi interrupt (t) 2 (th = 1) xmt. hold transparent mode flags fill code for flags in transp. mode a (tma only) crc select 0 1 crc generated/stripped crc to/from data section (hdlc mode only) inversion all rcv. and xmt. data bits in this channel are inverted. crc polynom 0 1 16 bit crc (hdlc mode) tmb tmr 1 0 interframe timefill 0 1 7e ff mode 0 0 tma 0 1 tmb/tmr 1 0 v.110/x30 1 1 hdlc mode flag adjustment/filtering fnum interframe timefill characters in hdlc mode, or tflag filtering in tma transmission rate of v.110/x30 0 0 0 1 1 0 1 1 600 bit/s, 7 repetitions 4.8, 9.6, 19.2, 38.4 kbit/s, no repetition itbs (buffer size) (ones) (flags) (hdlc mode) short frame (r) sfr: commands 001 fast rcv. abort fi interrupt (r) fast xmt. abort 001 111 not allowed 110 not allowed 101 100 011 010 xmt. off xmt. clear 000 xmt. abort xmt. jump xmt. init. nd xmt. commands : 32 bit crc (hdlc mode) 1200 bit/s, 3 repetitions 2400 bit/s, 1 repetitions
peb 20320 detailed register description user ? s manual 161 01.2000 4.2.6 current receive and transmit descriptor address for easier monitoring of the link lists the addresses of the just processed descriptors are written into the ccs. munich32 changes the current descriptor address at the same time when it branches to the next descriptor. 31 16 15 0 current receive descriptor address channel 0 . . . current receive descriptor address channel 31 current transmit descriptor address channel 0 . . . current transmit descriptor address channel 31
peb 20320 detailed register description user ? s manual 162 01.2000 4.3 transmit descriptor fe: frame end; this bit is valid in all modes. it indicates that after sending the data in the transmit data section ? the device generates an interrupt with fi bit set for hdlc, tmb, tmr, tma err bit set for v.110/x.30 ? the device then sends (fnum + 1) 7e h for hdlc, iftf = 0 7e, (fnum ? 1) ff h , 7e for hdlc, iftf = 1, fnum 1 7e for hdlc, iftf = 1, fnum = 0 (fnum + 1) 00 h for tmb, tmr (fnum 1) 000 h for tmr, fnum = 0 (fnum + 1) tflag for tma, fa = 1 (fnum +1) ff h for tma, fa = 0 three frames with synchronization errors for v.110/x.30 before starting with the data of the next transmit descriptor. if the data of the next transmit descriptor are not available in time (e.g. because the descriptor has fe and hold set) the device sends the interframe time-fill indefinitely. 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 fe hold hi no transmit data pointer next transmit descriptor pointer 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 v.110 0 0 0 csm fnum transmit data pointer next transmit descriptor pointer
peb 20320 detailed register description user ? s manual 163 01.2000 hold: if the munich32 detects a hold bit it ? generates an interrupt with err bit set if fe = 0 or v.110/x.30 mode ? sends the data in the current transmit data section ? generates the fcs bits for hdlc and cs = 0 and csm = 0 ? the device then sends at least (fnum + 1) 7e h for hdlc, iftf = 0 7e, fnum ff h for hdlc, iftf = 1 (fnum + 1) 00 h for tmb, tmr (fnum 1) 0000 h for tmr, fnum = 0 (fnum + 1) tflag for tma, fa = 1 (fnum + 1) ff h for tma, fa = 0 three frames with synchronization errors for v.110/x.30. ? it polls the hold bit and the next transmit descriptor address, but does no branch to a new descriptor until the hold bit is reset. the next transmit descriptor address is read but not interpreted as long as hold = 1. therefore it can be changed together with setting hold = 0. the polling occurs at most every 8 valid clock cycles of the channel and corresponds with internal requests from tf to tb. ? the device sends interframe time-fill until hold = 0 is polled. the hold condition is also discarded if a transmit jump, fast transmit abort or transmit initialization command is detected during the polling. the munich32 then branches to the transmit descriptor determined by ftda even though the hold bit of the current transmit descriptor may still be ? 1 ? . hi: host initiated interrupt; if the hi bit is set, munich32 generates an interrupt with set hi bit after transferring all data bytes. no: this byte number defines the number of bytes stored in the data section to be transmitted. a transmit descriptor and the corresponding data section must contain at least either one data byte or a frame end indication. otherwise an interrupt with set err bit is generated. v.110: this bit indicates that in the corresponding data section the e-, s- and x-bits of the following v.110/x.30 frame are stored. munich32 reads these bits and inserts them into the next possible v.110/x.30 frame. the data section may contain only two bytes specified in the next figure. the first transmit descriptor after a transmit initialization channel command must have this bit set if it revives the channel from a transmit off condition or after a pulse at the reset pin.
peb 20320 detailed register description user ? s manual 164 01.2000 intel mode motorola mode csm: crc select per message: this bit is only valid in hdlc mode with cs = 0 and only in conjunction with the fe bit set. if set, it means that no fcs is generated automatically for the frame finished in this transmit descriptor. fnum: fnum denotes the number of interframe time-fill characters between 2 hdlc or tmb frames. for x.30/v.110 these bits have to be set to ? 0 ? . fnum = 0 means that after the current frame only 1 character (7e h for hdlc and 00 h for tmb, 000 h for tmr, tflag, tflag for tma, fa = 1; ff h for tma, fa = 0) is sent before the following frame (shared flags). fnum = 1 means that after the current frame 2 characters (7e h 7e h for hdlc and 00 h 00 h for tmb and tmr, tflag, tflag for tma, fa = 1; ff ff h for tma, fa = 0) are sent before the following frame (non shared flags). fnum = 2 means that after the current frame 3 characters (7e h 7e h 7e h (iftf = 0) or 7e h ff h 7e h (iftf = 1) for hdlc and 00 h 00 h 00 h for tmb and tmr, tflag, tflag, tflag for tma, fa = 1; ff ff ff h for tma, fa = 0) are sent. 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 e7e6e5e4e3e2e1sbsax000000 15141312111098 7 6543210 0 0 00000 0 0 0 0 00000 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 0 0 00000000000000 15141312111098 7 6543210 sax00000 0e7e6e5e4e3e2e1sb
peb 20320 detailed register description user ? s manual 165 01.2000 fnum = k means that after the current frame k + 1 characters are sent (k + 1) times 7e h for itft = 0 and hdlc 7e h , (k ? 1) times ff h , 7e h for itft = 1 and hdlc (k + 1) times 00 h for tmb, tmr (k + 1) times tflag for tma, fa = 1 (k + 1) times ff h for tma, fa = 0. for hdlc mode fnum is reduced by one eight of the number of zero insertions if fa is set. if the reduction would result in a negative number of interframe time-fill characters it is set to 0. transmit data pointer: this 32-bit pointer contains the start address of the transmit data section. although munich32 works only long word oriented, it is possible to begin a transmit data section at an uneven address. the two least significant bits (add) of the transmit data pointer determine the beginning of the data section and the number of data bytes in the first long word of the data section, respectively. add: 00 = 4 bytes 01 = 3 bytes 10 = 2 bytes 11 = 1 byte munich32 reads the first long word and discards the unused least significant bytes. the no establishes (determines) the end of the data section, whereas the remainder of i (no add) 4 i defines the number of bytes in the last long word of the data section. munich32 reads the last long word and discards the unused most significant bytes of the last long word. if the first access is the same as the last access, add specifies the beginning of the data section and no the number of data bytes in the long word. all unused bytes are discarded.
peb 20320 detailed register description user ? s manual 166 01.2000 for example (intel mode): 1) add = 01, no = 8 2) add = 00, no = 8 3) add = 10, no = 1 for example (motorola-mode): 1) add = 01, no = 8 2) add = 00, no = 8 3) add = 10, no = 1 11 10 01 00 byte 2 byte 1 byte 0 ? byte 6 byte 5 byte 4 byte 3 3 long words are read ??? byte 7 11 10 01 00 byte 3 byte 2 byte 1 byte 0 byte 7 byte 6 byte 5 byte 4 2 long words are read ???? 11 10 01 00 ? byte 0 ?? ???? 1 long word is read! ???? 11 10 01 00 ? byte 0 byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 3 long words are read byte 7 ??? 11 10 01 00 byte 0 byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 2 long words are read 11 10 01 00 ?? byte 0 ? 1 long word is read!
peb 20320 detailed register description user ? s manual 167 01.2000 next transmit this 32-bit pointer contains the start address of the next transmit descriptor pointer: descriptor. after sending the indicated number of data bytes, munich32 branches to the next transmit descriptor to continue transmission. the transmit descriptor is read entirely at the beginning of transmission and stored in an on-chip memory. therefore all information in the next descriptor must be valid when munich32 branches to this descriptor when hold = 0. for hold = 1 the next transmit descriptor pointer is polled together with hold; the next transmit descriptor must be valid, when hold = 0 is polled. this pointer is not used if a transmit jump, fast transmit abort or transmit initialization channel command is detected while the munich32 still reads data from the current transmit descriptor or polls the hold bit. in this case ftda is used as a pointer for the next transmit descriptor to be branched to.
peb 20320 detailed register description user ? s manual 168 01.2000 4.4 receive descriptor the receive descriptor contains 4 long words; the first, third and fourth have to be written by the cpu, the second is written by the munich32 when it branches to the next receive descriptor or when it starts polling the hold bit. note: the munich32 branches to a next descriptor without writing the second long word if the receive initialization command is used during normal operation (see chapter 4.2.4 ) hold: setting the hold bit by the host prevents the device from branching to the next descriptor. the current data section is still filled. ? afterwards the second descriptor long word is written by the munich32. for hdlc, tmb, tmr the fe and c-bit is set. if the frame could not completely be stored into the data section the ra bit is set in the status. an interrupt with set fi bit is generated, and in case the frame was aborted, the err bit is also set. for tma, v.110/x.30 the c-bit and the ra bit is set and an interrupt with set err but with fi = 0 is generated. ? afterwards the device starts polling the hold bit, received data, and received events normally leading to interrupts (with rt = 1) are discarded until hold = 0 is polled. each 1 ? 4 byte data word or interrupt event normally leading to an access now results in a poll cycle. whenever hold = 1 is polled the next receive descriptor address is read but ignored. ? when hold = 0 is polled for hdlc, tmb, tmr the device continues to discard data until the end of a received frame or an event leading to an interrupt (with rt = 1) is 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 0holdhi no fe c 0 bno receive data pointer next receive descriptor pointer 15141312111098 7 6543210 0 0 00000 0 0 0 0 00000 status 0 0000000 receive data pointer next receive descriptor pointer
peb 20320 detailed register description user ? s manual 169 01.2000 detected. afterwards the next received frame is transferred into the next receive descriptor. interrupts are also generated again. for v.110/x.30, tma the device puts the next data into the next receive descriptor. interrupts are also generated again. the hold condition is also discarded upon detection of a receive jump, fast receive abort or receive initialization command. the munich32 then branches to the receive descriptor determined by frda even though the hold bit in the current receive descriptor may still be ? 1 ? . hi: host initiated interrupt; if the hi bit is set, munich32 generates an interrupt with set hi bit after receiving all data bytes. no: this byte number defines the size of the receive data section allocated by the host. because munich32 always writes long words the number of bytes (data section size) must be a multiple of 4 and greater or equal to 4. the maximum data section size is 8188 bytes. after reception of an hdlc frame with a data byte number not divisible by 4 munich32 first transfers the greatest entire ([number of data bytes/4]) in long words. then the remainder of the data bytes is transferred in another long word, where the non-significant bytes are filled with random values. they should not be interpreted. for example a hdlc frame with one data byte is received: the data bytes are stored into the receive data section according to the little endian convention (intel mode) or big endian convention (motorola mode). fe: frame end: the frame end bit is ? 1 ? only in hdlc, tmb, tmr mode and indicates that a receive frame has ended in this receive descriptor. for tma, v.110/x.30 the bit is always ? 0 ? . fe = 0 in hdlc, tme, tmr mode means that frame continues in the next receive descriptor or that it filled the current receive data section exactly (bno = no). in this case the next receive descriptor will have fe = 1, c = 1, bno = 0 and no data bytes are stored in the corresponding data section. c: this bit is set by munich32 if it completes filling the data section normally (bno = no) ? fe = 0, status = 00 it was aborted by a fast receive abort channel command ? status = 02 00000000.00001000.00000000.00000 11000000.00000001.status.00000000 receive data pointer next receive descriptor pointer receive descriptor xx.xx.xx.data receive data section
peb 20320 detailed register description user ? s manual 170 01.2000 for hdlc, tmb, tmr if the end of a frame was stored in the receive data section ? fe = 1, status gives the receive status determined by rd (interrupt with set fi bit is generated) for v.110/x.30 mode if the 3 contiguous frames with errors in the synchronization pattern are received ? fe = 0, status = 20 or status = 21 interrupt with set err bit for v.110/x.30 mode if the data could not be transferred to the shared memory due to rb buffer inaccessibility ? fe=0, status=01 or status = 21 interrupt with set err bit. c indicates that the second long word of the receive descriptor was written by the munich32. afterwards the munich32 writes the next receive descriptor address into ccs. then it branches to this descriptor immediately. bno: munich32 writes the number of data bytes it has stored in the current data section into bno. status: the munich32 writes the status information into the status byte whenever it sets the c-bit. if the status information is not 00 or 40 an interrupt with err bit set is generated. the status is then a means to locate or analyze the receive error. the following table gives a general overview over the different status bits in relation to the channel modes. hdlc cs = 0 0ni0ilnili i i hdlc cs = 1 000ilnili i i v.110/x.30 00i0 00 ifi tmb 0000 ili ifi tmr 0000 ili ifi tma 0000 00 if0 where ? 0 ? means that in the corresponding mode the bit is always ? 0 ? . it should not be interpreted though to be upward compatible to future versions. 76543210 0 sf loss crco nob lfd ra rof
peb 20320 detailed register description user ? s manual 171 01.2000 ni means the bit may be ? 1 ? or ? 0 ? but does not cause an interrupt with set err bit. iln means that it may be ? 1 ? or ? 0 ? but should not be evaluated if lfd or nob is also ? 1 ? . il means that it may be ? 1 ? or ? 0 ? but should not be evaluated if lfd = 1. i means that it may ? 1 ? or ? 0 ? . if means that it may be ? 1 ? only after a fast receive abort channel command or detection of a hold bit in the current receive descriptor. i, if, il, iln lead to an interrupt with err bit set. note: for hdlc, tmb, tmr the status word is only valid if the fe bit is set. the meaning of the individual status bits is as follows: sf = 1 (hdlc mode with cs = 0 only): the device has received a frame with 32 bit between start flag and end flag or end abort flag for crc16 48 bit between start flag and end flag or end abort flag for crc32 i.e. bno was 1 or 2. loss = 1 three contiguous frames with errors in the synchronization pattern were detected. crco = 1 a frame with a crc error was detected crco = 0 means the frame had no crc error. nob = 1 a frame whose bit content was not divisible by 8 was detected. nob = 0 means that the frame content was divisible by 8. lfd = 1 long frame detected. if this bit is set a frame whose bit content was > mfl was detected and aborted. the reception will be continued as soon as a flag is recognized. ra = 1 receive abort; this bit indicates that for hdlc: the frame was ended by an abort flag (7f h ) or by a receive abort command or a fast receive channel command or by a hold bit in the current receive descriptor. for v.110/x.30, tmb, tmr, tma that the frame or data were aborted by a fast receive abort channel command or a hold bit set in the current receive descriptor. rof = 1 an overflow of the internal buffer rb has occurred and lead to a loss of data. note: if rof without fo interrupt is generated for a channel for hdlc, tmb, tmr only the last part of one frame has been lost. for v.110/x.30 only data but no status information (change e-, s-, x-bits, loss) has been lost.
peb 20320 detailed register description user ? s manual 172 01.2000 note: in case of multiple errors all relevant bits are set. in case of rof = 1 only the error conditions of the frame within which the overflow occurred are reported. later frames that are aborted do not change the status. receive data pointer: this 32-bit pointer contains the start address of the receive data section. receive descriptor pointer: this 32-bit pointer contains the start of the next receive descriptor. it is not used if a receive jump, fast receive abort or receive initialize command is detected while the munich32 still writes data into the current receive descriptor or polls the hold bit. in this case frda is used as a pointer for the next receive descriptor to be branched to.
peb 20320 application notes user ? s manual 173 01.2000 5 application notes 5.1 test loops 5.1.1 test loop definitions for the munich32 two basic types of test loops are provided by the munich32, internal and external. each of these types is further subdivided into channelwise and complete test loops thus providing four possible test loops. 5.1.1.1 internal complete test loop the serial data output is physically routed to the serial data input. the tx data appears on the tdata output pin and the rdata input pin is ignored. tclk and rclk have to be identical; tsp and rsp have to be identical. the logical transmit and receive channels have to be programmed identically. figure 81 its08198 tdata 1 & cd rdata p interface enable int. complete loop & rsp rclk tclk tsp
peb 20320 application notes user ? s manual 174 01.2000 5.1.1.2 internal channelwise test loop one (and only one) logical channel is mirrored from the serial data output to the serial data input. the other logical channels are not affected by this operation. the transmit and receive data rates for this single logical channel must be identical. normal tclk, rclk, tsp and rsp design rules apply. this test loop provides channelwise testing capabilities during idle channel time slots, without interfering with normal data transmission/reception. figure 82 5.1.1.3 external complete test loop the serial data input is physically routed to the serial data output. data is received on the rdata pin and routed to the tdata pin. the received data can be stored in shared memory for additional diagnostic purposes. tclk and rclk have to be identical; tsp and rsp have to be identical. its08199 tdata 1 & cd channel x only rdata p interface enable int. channelwise loop for channel x
peb 20320 application notes user ? s manual 175 01.2000 figure 83 5.1.1.4 external channelwise test loop one (and only one) logical channel is mirrored from the serial data input to the serial data output. the other logical channels are not affected by this operation. the receive and transmit data rates for this single logical channel must be identical. normal tclk, rclk, tsp and rsp design rules apply. this test loop provides channelwise testing capabilities during idle channel time slots, without interfering with normal data reception/ transmission. figure 84 its08200 tdata 1 & cd rdata p interface enable ext. complete loop & rsp rclk tclk tsp its08201 tdata 1 & cd channel x only rdata p interface enable ext. channelwise loop for channel x
peb 20320 application notes user ? s manual 176 01.2000 5.1.2 test loop activation all of the test loops are closed (activated) and opened (deactivated) by setting/resetting the appropriate combination of bits in the a ction sp ecification ( table 10 ). any unlisted combination of loc, loop and loopi is an invalid operation. although the data sheet (data sheet 08.93) specifically states that loops must be left (opened) by issuing the reset pin to ? 1 ? , there are exceptions to this rule. generally, the test loops can be opened by software. there are several cases that must be examined and these will be discussed in the next section. when closing (activating) a test loop, the in, ico, im, res, and ia bits should equal ? 0 ? and pcm and mfl should be set to the appropriate values. the following recommended procedure for activating a test loop assumes that the munich32 has been fully initialized and the user desires to activate a test loop on channel x : initialize rc and tx channel as appropriate for type of test loop. close (activate) the test loop. perform test functions (transmit/receive data, check for interrupts, errors, etc.) open (deactivate) the test loop. perform rc and tx off function. note: while the test loop is activated, do not execute the transmit off command. it will not have the effect of resetting the transmit formatter. 5.1.3 test loop deactivation and switching as mentioned previously, a test loop can be opened (deactivated) by software. to deactivate a test loop a new asp should be issued with loc, loop, and loopi = 0 and all other bits should be set to the previous values used during activation. listed below are the possible test loop operations that can be activated with software and those requiring a hardware reset. table 11 is provided as a graphical representation of this information. table 10 test loop activation test loop loc loop loopi asp internal complete 0 0 1 xxxxxx08 h internal channelwise 1 0 1 xxxxxx28 h external complete 0 1 0 xxxxxx10 h external channelwise 1 1 0 xxxxxx30 h no loop 0 0 0 xxxxxx00 h
peb 20320 application notes user ? s manual 177 01.2000 5.1.3.1 software operations close and open internal complete loop. close and open internal channelwise loop. close and open external complete loop. close and open external channelwise loop. change from internal complete loop to internal channelwise loop. change from external complete loop to external channelwise loop. 5.1.3.2 hardware reset operations change between the internal complete loop and external complete loop. change between the internal channelwise loop and external channelwise loop. change between the internal channelwise loop and internal complete loop. change between the external channelwise loop and external complete loop. change between internal channelwise loop and external complete loop. change between internal complete loop and external channelwise loop. change between external channelwise loop and internal complete loop. change between external complete loop and internal channelwise loop. table 11 allowed operations change to internal complete loop internal channelwise loop external complete loop external channelwise loop internal complete loop x sfw hdw reset required hdw reset required internal channelwise loop hdw reset required x hdw reset required hdw reset required external complete loop hdw reset required hdw reset required x sfw external channelwise loop hdw reset required hdw reset required hdw reset required x
peb 20320 application notes user ? s manual 178 01.2000 5.1.4 test loop examples 5.1.4.1 internal channelwise test loop generate hw reset, and hold off rsp/tsp for 1000 sclk cycles. asp: a104-8004 ;cept, mfl=260, in, ia=1 iqs: icq 0000-001f tsa[0]: 00ff-00ff ;ts0 = ch0 tsa[1?31]: 0000-0000 ( 31) csp[0]: 00e9-0006 ;tx/rc init, poll tx desc, hdlc frda ftda 0000-0002 ;itbs = 2 long words csp[1?31] 0000-0000 0000-0000 0000-0000 0000-0000 (x31) cra[0?31] 0000-0000 ( 32) cta[0?31] 0000-0000 ( 32) icq: 0000-0000 ( 512) frda: 0020-0000 0000-0000 rcvdtaptr ? 32 byte +?? nxtrdptr data block ? +? 0020-0000 0000-0000 rcvdtaptr ? 32 byte +?? nxtrdptr data block ? +? 0020-0000 0000-0000 rcvdtaptr ? 32 byte +?? nxtrdptr data block ? +? 4020-0000 ;hold = 1 0000-0000 rcvdtaptr ? 32 byte 0000-0000 data block ftda: c000-0000 ; hold, fe = 1 for dummy frame xmtdtaptr +?? nxttdptr ? +? 0020-0000 xmtdtaptr ? abcdefghijklmnop +?? nxttdptr qrstuvwxyz012345 ? +? c020-0000 ;fe, hold = 1 xmtdtaptr ? abcdefghijklmnop 0000-0000 qrstuvwxyz987654
peb 20320 application notes user ? s manual 179 01.2000 generate ar pulse and wait for int signal (set up ts0 and ch0). read interrupt queue: icq: 9000-8000 ;action request acknowledge ;v2.2 (v2.1 = 8800-8000) 9000-1000 ;polls hold bit of 1st tx desc. set asp for internal channelwise loop test asp: a104-0028 ;cept, mfl=260, int. chnl loop generate ar pulse and wait for int signal. read interrupt queue: icq: 9000-8000 ;action request acknowledge 9000-1000 ;polls hold bit of 1st tx desc. 9000-082020 ;rc itf state change clear hold bit in ftda (allow frame to tx over internal chnl. loop). read interrupt queue: icq: 9000-1000 ;end of tx frame, polling hold bit of tx desc. 9000-1020 ;rc frame complete read receive descriptors: frda: 0020-0000 4020-0000 ;c = 1, no = bno rcvdtaptr ? abcdefghijklmnop +?? nxtrdptr qrstuvwxyz012345 ? +? 0020-0000 4020-0000 ;c = 1, no=bno rcvdtaptr ? abcdefghijklmnop +?? nxtrdptr qrstuvwxyz987654 ? +? 0020-0000 c000-0000 ;fe, c = 1, bno = 0 rcvdtaptr ? ;empty! (p. 139 user ? s manual - fe description) +?? nxtrdptr ? +? 4020-0000 0000-0000 rcvdtaptr ? 32 byte 0000-0000 data block
peb 20320 application notes user ? s manual 180 01.2000 5.1.4.2 external channelwise test loop generate hw reset, and hold off rsp/tsp for 1000 sclk cycles. asp: a104-8004 ;cept, mfl=260, in, ia=1 iqs: icq 0000-001f tsa[0]: 00ff-00ff ;ts0 = ch0 tsa[1 ? 31]: 0000-0000 ( 31) csp[0]: 00e9-0006 ;tx/rc init, poll tx desc., hdlc frda ftda 0000-0002 ;itbs = 2 long words csp[1 ? 31] 0000-0000 0000-0000 0000-0000 0000-0000 (x31) cra[0 ? 31] 0000-0000 ( 32) cta[0 ? 31] 0000-0000 ( 32) icq: 0000-0000 ( 512) frda: 0020-0000 0000-0000 rcvdtaptr ? 32 byte +?? nxtrdptr data block ? +? 0020-0000 0000-0000 rcvdtaptr ? 32 byte +?? nxtrdptr data block ? +? 0020-0000 0000-0000 rcvdtaptr ? 32 byte +?? nxtrdptr data block ? +? 4020-0000 ;hold = 1 0000-0000 rcvdtaptr ? 32 byte 0000-0000 data block ftda: +? c000-0000 ;hold, fe = 1 for dummy frame ? xmtdtaptr +?? nxttdptr
peb 20320 application notes user ? s manual 181 01.2000 generate ar pulse and wait for int signal (set up ts0 and ch0). read interrupt queue: icq: 9000-8000 ;action request acknowledge ;v2.2 (v2.1 = 8800-8000) 9000-1000 ;polls hold bit of 1st tx desc. 9000-1000 ;fi frame indication for the 1st tx desc. ;now m32 starts polling hold bit of 1st desc. set asp for external channelwise test loop asp: a104-0030 ;cept, mfl=260, ext. chnl loop generate ar pulse and wait for int signal. read interrupt queue: icq: 9000-8000 ;action request acknowledge 9000-0820 ;only if other station uses idle code 7e 9000-1020 ;received frame complete read receive descriptors: ;assumes 64 byte frame externally looped frda: 0020-0000 ;with proper hdlc framing 4020-0000 ;no = bno rcvdtaptr ? abcdefghijklmnop +?? nxtrdptr qrstuvwxyz012345 ? +? 0020-0000 4020-0000 ;no=bno rcvdtaptr ? abcdefghijklmnop +?? nxtrdptr qrstuvwxyz987654 ? +? 0020-0000 c000-0000 ;fe, c = 1, bno = 0 rcvdtaptr ? ;empty! +?? nxtrdptr ? +? 4020-0000 0000-0000 rcvdtaptr ? 32 byte 0000-0000 data block
peb 20320 application notes user ? s manual 182 01.2000 5.2 munich32 in a lan/wan router 5.2.1 introduction subject of this application note is an isdn/lan router, a communication system that enables two lans to communicate via the isdn. figure 85 isdn/lan router the structure of the whole system is shown in figure 85 . the router itself is realized as a stand alone solution. it is connected to a standard pc for software download and maintenance control only. after the download the system works fully independent of the host pc. the hardware of the isdn/lan router consists of an application specific part and a processor system. the application specific hardware is mainly based on the siemens component munich32 (multi channel network interface controller for hdlc) and a standard lan controller. both devices are integrated in the same processor system. the software of the isdn/lan router is formed by integrating the munich32 device driver module (ddm) and the corresponding lan controller device driver module in a device driver system (dds). the device driver modules build a platform to implement the routing strategy in a separate application module. the application specific hardware, the munich32 device driver module and the application module are the main aspects described in the following chapters. the structure of the processor system is briefly illustrated. the dds service routines are explained as far as necessary to understand this special application. it is suggested that the reader has some knowledge about the munich32 before reading this application note. detailed information about the munich32, its features and memory structures are given in the munich32 PEB20320 data sheet. its08283 router router isdn lan lan
peb 20320 application notes user ? s manual 183 01.2000 5.2.2 hardware the processor system is based on a motorola 68040 processor. it contains 512 kbyte sram, a bus controller and peripherals like timer, eprom and interrupt controller. the application specific hardware is integrated by using a peripheral connector and an alternate busmaster connector. the peripheral connector allows the integration of external peripherals. the alternate busmaster connector is used to connect external bus masters to the local bus. the system is provided with a rs232 serial interface to download executable software on the board. figure 86 hardware block diagram itb08284 timer eprom interrupt controller sram alternate busmaster connector peripheral connector bus controller mc68040 i82596 munich32 i82c501 em 2 connector connector acfa pract rs232 isdn interface interface lan glue logic lan isdn
peb 20320 application notes user ? s manual 184 01.2000 application specific hardware the application specific hardware consists of an isdn primary rate interface and an ethernet interface. the munich32 peb 20320 in conjunction with the layer 1 siemens components acfa (advanced cmos frame aligner) peb 2035 and pract (primary rate access clock generator and transceiver) peb 22320 are used to build the primary rate interface. incoming data from the isdn is first processed from the pract. it translates the hdb3 coded line signals in dual rail signals. the pract also supplies acfa and munich32 with clock signals. main task of the acfa is the frame alignment. besides, the acfa translates the dual rail data in a single rail, unipolar bit stream which can be processed by the munich32. the munich32 handles up to 32 channels of a full duplex pcm highway. all time-slots may have data rates between 8 kbit/s and 64 kbit/s. the munich32 supports besides other protocols the hdlc formatting/deformatting. if programmed for hdlc mode, the munich32 performs hdlc specific functions like framing, crc check/generation, flag stuffing and zero bit insertion/deletion autonomously. an on-chip 64-channel dma controller allows the device to store/read data into/from the sram. the dma controller manages long word or word transfers via a 32-bit processor interface. the p interface can be configured to be motorola 68020 or intel 80386 compatible. figure 87 isdn interface the ethemet interface is built with a lan controller, a manchester encoder/decoder and a transceiver. the lan controller supports all ieee 802.3 standards. the ethernet framing: preamble generation, source address generation, destination address checking, short-frame detection, automatic length field handling is performed. after lan controller processing the transmit data is manchester encoded and forwarded to the transmission line, while receive data is manchester decoded before being processed by the lan controller. its08285 munich32 acfa pract line in line out overvoltage p interface pcm highway dual rail unipolar signals
peb 20320 application notes user ? s manual 185 01.2000 system architecture the system architecture is shown in figure 88 . the munich32, the cpu and the lan controller store data in the shared memory. the communication between cpu and alternate bus master is done via the shared memory. the cpu informs the alternate bus masters with help of control signals about changes in the shared memory and vice versa. the munich32 input control signal is the action request pulse (action request). it is generated by one cpu write cycle to a defined address and decoding the address lines. the munich32 then responds by generating an interrupt pulse and writing the respective interrupt information in the sram. figure 88 system architecture its08286 munich32 cpu i82596 signals control control signals local bus shared memory
peb 20320 application notes user ? s manual 186 01.2000 bus arbitration since three devices are using the bus it is necessary to implement a bus arbitration. each bus master requests bus mastership and awaits bus control given to it by the arbiter. the bus arbitration protocol is also motorola specific. the intel specific signals of the lan controller (i82596) are translated into motorola specific signals. the bus arbitration is realized in two devices gal16v8 (15 ns), both containing a finite state machine. arbiter 1 gives bus mastership to the cpu whenever no other bus master requests bus mastership. if either the munich32 or the lan controller requests bus mastership the arbiter 2 gives a bus request to the arbiter 1. arbiter 1 forces the cpu to release the bus and gives bus mastership to arbiter 2. arbiter 2 then responds to munich32 or lan controller. in this solution the priority of the munich32 is higher than that of the lan controller. consequently if both alternate bus masters request bus mastership at the same time, bus mastership will be given to the munich32. the lan controller has to wait until munich32 has finished his accesses and arbiter 1 returns the bus to the cpu. it might happen, that some ethernet frames get lost, because the lan controller can not get access to the bus in time, but the loss of incoming data from the isdn (where fees have to be paid) is minimized. figure 89 bus arbitration its08287 munich32 cpu i82596 arbiter 1 arbiter 2
peb 20320 application notes user ? s manual 187 01.2000 bus timing adaptation 1) the bus controller manages memory accesses of all bus masters (cpu, munich32 or lan controller). the bus controller timing is motorola 68040 specific. the munich32 bus interface is either intel specific or motorola 68020/030 specific. therefore the munich32 bus timing needs to be adapted by using simple glue logic. one gate array logic (gal16v8, 15 ns) contains all necessary logic. the munich32 address strobe (as ) signal determines valid addresses on the bus. the equivalent motorola 68040 control signal is the transfer start (ts ). during munich32 write cycles valid data on the bus is indicated with the data strobe (ds ) signal. munich32 write and read bus cycles are terminated with the data transfer acknowledge (dsack ) signal. for the motorola 68040 the end of a bus cycle is indicated by the transfer acknowledge (ta ) signal. during munich32 bus cycles the munich32 output signal as is used to generate the bus controller input signal ts . the ts is deasserted with the munich32 input dsack rising edge. since all bus cycles have the same length the dsack signal is generated two bus clock cycles after as is detected low. ts is tristated, if the munich32 is not busmaster. this signal is driven by another bus master during that time. figure 90 munich32 timing adaption 1) see also chapter 5.2.6 . itd08288 bclk sclk ts ta addr data as dsack
peb 20320 application notes user ? s manual 188 01.2000 the lan controller ? s (i82596) bus timing also needs to be adapted. the address lines a1, ao, size 0 and size 1 need to be generated, because the lan controller performs 8 bit and 16 bit cycles as well as 32 bit cycles. there are also some non standard bus signals for the lan controller, that have to be generated. furthermore the system clock and the bus clock have to be synchronized. all necessary glue logic for the lan controller is realized in four devices gal 16v8. 5.2.3 software the software is based on a message oriented device driver system. the device driver modules and application modules have a structure that allows to access them via defined entry points. module entry points two entry points offer access to the ddms. messages can be sent to the ddm via the message entry point. a hardware interrupt causes the program to branch to the interrupt entry point. the apm also offers access via a message entry point, but since the apm does not control any hardware, there does not exist any interrupt entry point. figure 91 module entry points its08289 device driver system device driver module application module message message hardware interrupt
peb 20320 application notes user ? s manual 189 01.2000 dds tasks the message transfer between the modules is the main task of the dds, realized by some service routines. ddms and apms are integrated in the dds by executing a module init routine. the module init routine is called by the dds. additionally the dds offers service routines for memory management. all service routines can be used by all modules. some memory management functions will be presented in more detail. for detailed information about the other dds service routines please refer to the sipb 7520 primary rate user board or easy532 datacom userboard documentation. memory management with the memory management functions the allocation of message descriptors, munich32 receive/transmit descriptors 1) or lan controller receive/transmit descriptors is simplified. during initialization of the memory management module ddsm a pool of descriptors is prepared in a linked list. the memory management functions allow to allocate descriptors and to free descriptors. during initialization of the memory management module ddsm a pool of descriptors is prepared in a linked list. the memory management functions allow to allocate descriptors and to free descriptors. during allocation a descriptor is taken from the prepared list. after utilization the descriptor is given back to the descriptor pool. there is one pool for message descriptors and one pool for munich32 receive/transmit and lan controller receive/transmit descriptors. because munich32 transmit and receive descriptors differ and they both differ from the lan controller transmit and receive descriptors, there are service functions available to convert the descriptor type. 1) refer to munich32 data sheet.
peb 20320 application notes user ? s manual 190 01.2000 figure 92 memory management its08290 message descriptor pool allocate free free allocate convert munich32/lan controller descriptor pool
peb 20320 application notes user ? s manual 191 01.2000 5.2.3.1 device driver module munich32 tasks the munich32 device driver module has to prepare all memory structures for the munich32. the action request pulse has to be generated. the device driver module also has to treat the munich32 interrupts. message entry point every incoming message results in executing a function. function action resetmunich32 action specification reset bit is set, all channels are initialized, all time-slots are initialized, action request pulse is generated. configmunich32 sets pcm mode and maximum frame length, action request pulse is generated. initlnterruptqueue interrupt attention bit is set, a new interrupt queue is defined, action request pulse is generated. initchannel action specification in-bit is set, initializes receiver and transmitter of selected channel, action request pulse is generated. inittxchannel initializes transmitter of selected channel, action request pulse is generated. initrcchannel initializes receiver of selected channel, action request pulse is generated. sendframe adds tx descriptors to the transmit descriptor queue and clears hoid bit of poll descriptor if the channel is active. txjump if no poll descriptor is detected initialize channel only bit is set, ? transmit jump ? command is given, if the previous command was not ? receive abort ? or ? off the receive clear ? command is given, action request pulse is generated. txhold initialize channel only bit is set, turns channel on or off, turn channel on: if last command was ? transmit off ? or ? transmit abort ? ? transmit clear ? is given and ? transmit hold ? bit is cleared, turn channel off: if channel is active and ? transmit hold ? bit is set, action request pulse is generated.
peb 20320 application notes user ? s manual 192 01.2000 interrupt entry point the information in the interrupt queue is read and a message containing that information is sent to the user. in case of a received frame the written receive descriptors are linked to a message and sent to the user. the next available descriptor in the list is linked to the memory structures. an equivalent number of new receive descriptors is allocated and linked to the end of the receive descriptor queue. in case of a transmit acknowledge interrupt the used transmit descriptors are released to the descriptor pool. txshutdown initialize channel only bit is set, gives ? transmit off ? command or ? transmit abort ? command, action request pulse is generated. rcjump initialize channel only bit is set, if last command was ? transmit off ? or ? transmit abort ? ? transmit clear ? is given, ? receive jump ? command is given, action request pulse is generated. rcshutdown ? initialize channel only ? bit is set, gives receive off command if receiver was aborted otherwise gives receive abort command, action request pulse is generated. switchlnternalchanloop sets/clears internal channelwise loop, action request pulse is generated. switchlnternalcomploop sets/clears complete loop, action request pulse is generated. showmunich32versionnr action request pulse is generated. checkactionrequestqueue looks for messages to be processed and branches to the message entry point. function action
peb 20320 application notes user ? s manual 193 01.2000 programming the munich32 for this application the basic programming of the munich32 for this application is realized in the module initialization routine. further programming is done by calling the function ? init channel ? for each channel once. transmit data is then added to the memory structures by passing a message with linked transmit descriptor(s) to the function ? send frame ? . module initialization routine here the im-bit is cleared because the munich32 ddm expects the action request acknowledge interrupt. the values for pcm and mfl are set. the pcm format is a 32- channel format according to cept. the maximum frame length is set to its maximum. finally the address and length of a new interrupt queue are defined. those values will not be changed anymore. init channel routine the function ? init channel ? initializes the time-slot assignment and the channel specification for one channel. the channel number is set to the value of the variable ? channel ? . the munich32 is alerted to access all time-slot assignments and the channel specification by setting the in-bit. the fillmask (transmit and receive) for the selected channel is written in the appropriate word of the time-slot assignment. all other channels and their fillmasks are not affected. for this application all interrupts are enabled. initialization of the selected channel comprises the definition of a new itbs value and initialization of the receiver and the transmitter. the transmit hold bit is cleared. after initialization the munich32 starts polling the hold bit of the current transmit descriptor. therefore a transmit descriptor is allocated and connected to the memory structures. its hold bit and fe-bit are set to one, its no-bits are set to zero. for that reason the munich32 does not transmit anything but polls this descriptor. since after the receiver ? s initialization the munich32 is ready to receive data, a queue of receive descriptors is allocated and linked to the memory structures. the hold bit of the last descriptor in the list is set to indicate the end of the list. in all other descriptors the hold bit is cleared.
peb 20320 application notes user ? s manual 194 01.2000 send frame routine calling ? sendframe ? after initialization of a channel results in executing ? addhdlcframe ? . in that routine the transmit descriptors are disconnected from the message and linked to the memory structures. if the message source is the ? mroute application module ? the hold bit and fe-bit indicating the end of a frame and the end of the list have already been set/cleared in the mroute module, they are not modified anymore. if the message source is any other module the fe-bit and hold bit are cleared in all descriptors except for the last one. there the hold bit has to be set, to prevent the munich32 from branching to the next descriptor. setting the fe-bit in the last descriptor only forces the munich32 to send the data in one hdlc frame. the bits hi, v110 and csm are cleared in both cases. transmit/receive interrupt a transmit acknowledge interrupt is treated by returning the transmit descriptor(s) to the descriptor pool. after a receive interrupt (fi bit set) the receive descriptors with c-bit set, are disconnected from the list of receive descriptors, linked to a message and sent to the mroute module. the next free receive descriptor in the list is linked to the memory structures. an equivalent number of new descriptors is allocated and linked to the end of the receive descriptor list. 5.2.3.2 application module mroute the application module mroute implements the routing strategy. routing strategy both devices the munich32 and the lan controller organize receive and transmit data in a linked list of receive descriptors and a linked list of transmit descriptors. the data is stored in data buffers of variable size. the receive/transmit descriptors contain the address of the data buffer. the basic idea behind the routing strategy is, to take the munlch32 ? s receive descriptor and link it to the lan controller ? s transmit descriptor queue. on the other hand to take the lan controller ? s receive descriptor and link it to the munlch32 ? s transmit descriptor queue.
peb 20320 application notes user ? s manual 195 01.2000 figure 93 insertion of additional information to make efficient use of the available bandwidth, the parallel use of several b-channels is one of the routing strategy ? s goals. every ethernet frame is divided into several parts because the lan controller stores the received data in several receive descriptors, if necessary. the frame is then sent via the isdn by using a separate b-channel for every lan receive descriptor. to ensure that the parts of the ethernet frame will be reassembled in correct order, every part of the ethernet frame is supplied with additional information. that additional information has to be extracted before reassembling the frame. in figure 93 an example of one ethernet frame consisting of three descriptors, spread over two b-channels, is shown. the additional information contains the frame number, the descriptor number and the information, whether the frame is completed. to simplify the extraction of the additional information every frame part and its additional information are sent in one hdlc frame. its08291 0 frame count descr count eof = 0 1 = eof count descr count frame 2 fe = set set = fe ch 1 2 ch set = fe 1 = eof count descr count frame 1 0 12 eof = set isdn 64 kbit/s each channel max 10 mbit/s lan
peb 20320 application notes user ? s manual 196 01.2000 the fe-bit marks the end of one hdlc frame, the eof bit marks the end of the ethernet frame. the additional information comprises the 8-bit word descriptor count, 16-bit word frame count and eof a 8-bit variable which indicates the last descriptor of the frame. message entry point the message entry point calls two functions: isdnrouteframe and lanrouteframe. an ethernet frame is processed by isdnrouteframe, an isdn frame by lanrouteframe. the munich32 receive descriptors are converted to lan controller transmit descriptors and those of the lan controller are converted to munich32 transmit descriptors. figure 94 message flow between ddms and mroute module besides the isdnrouteframe realizes the insertion of additional information and splits an ethernet frame on several b-channels. the additional information is stored in an extra allocated transmit descriptor which is placed before the descriptor containing the data. every descriptor and the respective extra descriptor are connected to one message descriptor. this message with set hold bit and set fe-bit in the descriptor containing the data is further processed from the munich32 ddm routine ? send frame ? . lanrouteframe reassembles the ethernet frames. it takes into account, that the parts might arrive with different delays. every complete frame is connected to a message descriptor and than processed from the lan controller ddm. munich32 ddm ddm lan controller isdn route frame lan route frame mroute module munich32 tx descr rc descr munich32 message descr tx descr lan controller rc descr lan controller message descr its08292
peb 20320 application notes user ? s manual 197 01.2000 5.2.4 performance considerations some considerations about the performance are made by investigating the maximum data rate. further investigations are made about the bus occupancy by all busmasters and the munich32 poll access ? influence on the data rate. finally the processing of one frame is illustrated. data rates the data rate during transmission from the isdn into the ethernet was tested. figure 95 data rate the size of one data buffer is 128 byte. if the number of channels exceeds 24 the data rate depends on the munich32 transmitter. if the transmitter is initialized the data rate decreases. this shows the influence of the munich32 polling the hold bit. itd08293 036912151821242730 channels 0 200 400 600 800 1000 1200 1400 1600 1800 2000 kbit/s data rate available data rate without munich32 polling data rate with munich32 polling
peb 20320 application notes user ? s manual 198 01.2000 bus occupancy the bus occupancy during normal operation is shown in figure 96 . in this case the data buffer size was 32 byte. the cpu has busmastership during 90% of the time. the munich32 as well as the lan controller, each have busmastership 5% of the time. the bus occupancy of the munich32 is calculated to 2.5% 1) . in this system it is higher because of inserted wait states in every bus cycle. another reason is the bus controller ? s clock which is switched from 33 mhz to 40 mhz. this and the existence of two alternate bus masters results in a more time consuming arbitration protocol than that needed for a simpler architecture. figure 96 bus occupancy 1) compare data sheet. itd08294 i82596 5 % m32 5 % cpu 90 %
peb 20320 application notes user ? s manual 199 01.2000 munich32 polling the influence of the polling can be illustrated by showing the bus occupancy of munich32 poll accesses only. figure 97 bus occupancy during polling here the munich32 is polling 31 channels (= 31 2 read accesses during 125 s). every access is 5 clock cycles long, instead of the minimum length of 4 clock cycles. the time for the arbitration protocol needed during every access results in bus idle time. itd08295 idle % 10 m32 17 % cpu 73 %
peb 20320 application notes user ? s manual 200 01.2000 frame processing during normal operation the processing of a frame comprises three consecutive parts. during transmission from isdn to lan the frame is first processed from the munich32, then from the cpu and finally from the lan controller. figure 98 frame processing though the cpu is never idle, its part on frame processing is that between the munich32 and the lan controller are active. the time to process one frame is the minimum delay required between frames during continuous transmission. itd08296 munich32 cpu i82596 t frame 1 frame 2
peb 20320 application notes user ? s manual 201 01.2000 5.2.5 final remarks this application note shows a design example for the munich32 (peb 20320). though the design example is of reduced complexity it gives an idea of how to use the munich32 in a system. the munich32 is integrated in a 68040 processor system in conjunction with one more alternate bus master. to achieve higher data rates the time to process the frames should be minimized. this includes minimization of bus idle time. the bus arbitration still has big improvement potential because of its modular structure. additionally the existence of the alternate bus masters results in clocking the bus controller with two different frequencies. this also results in increased idle time for the bus should therefore be modified. furthermore frame processing could be shortened by eliminating the wait states in every bus cycle. the influence of munich32 poll accesses is extremely high in this example, because of the bus arbitration architecture and the system architecture with one bus controller for all bus masters. but anyway it should always kept in mind, that the bus occupancy during polling is higher than during transmission. during transmission it decreases rapidly. no upper layer software is realized in this example so far. for ? real life ? routing layer 2 and 3 software module(s) have to be integrated.
peb 20320 application notes user ? s manual 202 01.2000 figure 99 integration of upper layer software its08297 message descr munich32 rc descr tx descr munich32 munich32 ddm ddm lan controller message descr lan controller tx descr lan controller rc descr isdn route frame lan route frame mroute module upper layer software software upper layer
peb 20320 application notes user ? s manual 203 01.2000 5.2.6 adaption of the 68040 p signals begin header this gal is used to adapt the 68040 -processor signals to the munich32. it is used in a system with a frequency relationship of 1/2 pclk/sclk. end header begin definition device gal1 6v8; {select the device to be gal16v8} input bclk = 1, m32asq = 2, reset = 3, m32bgackq = 4, int = 5, acreqm68 = 6, rwq = 7, clk = 8, {= musclk} rclk = 9; feedback (com) dsackq = 19; output (com) tsq = 18, resetq = 17, intq = 16, acreqm32 = 15, sclk = 14; statebits sb2 = 13, sb1 = 12; state_names idle = 2, one = 1, two = 0; end definition
peb 20320 application notes user ? s manual 204 01.2000 begin equations tsq.oe = /m32bgackq; tsq = /(/m32asq dsackq); resetq = /reset; intq = int; acreqm32 = /(/acreqm68 reset /rwq); sclk = (/reset rclk) + (reset /clk); end equations begin state_diagram tktadaptor (sb2, sb1) state all: if (/reset + m32asq) then idle with dsackq = 1; endwith; state idle: dsackq = 1; if (/m32asq reset) then one else idle; state one: dsackq = 1; go to two; state two: dsackq = 0; if m32asq then idle else two; end state_diagram
peb 20320 application notes user ? s manual 205 01.2000 5.2.7 schematics figure 100 its08298 lan interface serint.sch lan_cont.sch mubgq mubgoq mubgackq mubrq bgq bgackq brq isdn easy320.sch ser_int mubgq mubgoq mubgackq mubrq bgq bgackq brq ctrl a d ctrl a d
peb 20320 application notes user ? s manual 206 01.2000 figure 101 its08299 1 p 5 17 4 16 3 15 2 14 1 18 6 19 7 20 8 21 9 13 25 12 24 11 23 10 22 gnd 1 3 2 jp1 gnd cc v lin1 fsq lin2 lout1 lout2 sync clk4m clk2m xclk acfa_pract acfaprac.sch munich32 munich32.sch pclk3 rtclk trsp pclk3 clk2m fscq xdi rdo tdata rdata connector db25 female
peb 20320 application notes user ? s manual 207 01.2000 figure 102 its08300 j1a 32 a 32 31 31 30 30 29 29 28 28 27 27 26 26 25 25 24 24 23 23 22 22 21 21 20 20 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 1 vg96 a a a a a a a a a a a a a a a a a a a a a a a a a a a a a2 3 4 5 6 7 8 9 11 19 21 29 31 10 12 13 14 15 16 17 18 20 22 23 24 25 26 27 28 30 30 28 27 26 25 24 23 22 20 18 17 16 15 14 13 12 10 31 29 21 19 11 9 8 7 6 5 4 3 2 vg96 65 1 66 2 67 3 68 4 69 5 70 6 71 7 72 8 73 9 74 10 75 11 76 12 77 13 78 14 79 15 80 16 81 17 82 18 83 19 84 20 85 21 86 22 87 23 88 24 89 25 90 26 91 27 92 28 93 29 94 30 95 31 32 d 96 j1c d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d0 1 u1 munich32 100 be0 1 be 96 2 be 94 3 be 91 102 a a2 3 a a 107 4 a a 109 5 a a 114 6 a a 116 7 a a 120 8 a a 122 9 a a 126 10 a a 128 11 a a 133 12 a a 135 13 a a 139 14 a a 143 15 a a 147 16 a a 149 17 a a 154 18 a a 156 19 a a 160 20 a a 2 21 a a 6 22 a a 8 23 a a 13 24 a a 15 25 a a 19 26 a a 21 27 a a 26 28 a a 28 29 a a 33 30 a a 35 31 a a 39 32 29 29 27 28 28 25 27 27 20 26 26 18 25 25 14 24 24 12 23 23 7 22 22 5 21 21 1 20 20 159 19 19 155 18 18 153 17 17 148 16 16 146 15 15 142 14 14 138 13 13 134 12 12 132 11 11 127 10 10 125 9 9 121 8 8 119 7 7 115 6 6 113 5 5 108 4 4 106 3 3 101 2 2 99 1 1 0 d 0 d 95 d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d 30 31 38 34 d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d31 30 90 w,r/r,w 85 ads/as 86 ds 75 ready/dsack 76 berr 74 b 82 hold/br 79 hlda/bg 81 pm 80 hldao/bgo 66 ar 40 int/int 16 muintq crstq addwsq pcsq5 wrq bgackq m32bgq lockq bgq tsq bclk bbq vg96 33 1 34 2 35 3 36 4 37 5 38 6 39 7 40 8 41 9 42 10 43 11 44 12 45 13 46 14 47 15 48 16 49 17 50 18 51 19 52 20 53 21 54 22 55 23 56 24 57 25 58 26 59 27 60 28 61 29 62 30 63 31 32 musclk 64 j1b 2 jp 12 gnd cc v mubgoq mubgq rclk 44 45 rsp rdata 46 69 tclk tsp 68 tsp 67 ? k 4.7 1 rp 89 7 10 6 11 5 12 4 13 3 14 2 15 16 1 cc v mubgackq u7 oe 11 musclk clk 8 9 7 8 7 6 5 6 4 5 3 4 3 2 1 2 gal16v8 12 o8 7 o 13 14 o6 sclk 61 15 o5 16 o4 17 o3 60 reset 18 o2 o1 19 dsackq 56 3 jtest jtest 2 55 jtest 1 54 jtest 0 53 19 1 o 2 o 18 3 o 17 4 o 16 5 o 15 6 o 14 13 o7 8 o 12 gal16v8 2 1 2 3 4 3 5 4 6 5 6 7 8 7 9 8 clk 11 oe u8 gnd bclk m32bgq mubrq cc v 1 r 3.3 k ? brq bgackq m32bgq pclk3 tdata rdata trsp rtclk gnd cc v 1 c 100 nf nf 100 c 2 nf 100 c 3 nf 100 c 4 nf 100 c 5 nf 100 c 6 nf 100 c 7 nf 100 c 8 nf 100 c 9 nf 100 c 10 nf 100 c 11 nf 100 c 12 nf 100 c 13 nf 100 c 14 asq crstq mubgackq int pcsq5 rwq tsq muintq gnd crstq bbq lockq brq bgackq 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 pclk3 bgq 0 ci 1 2 3 47 48 49 50 4 51 ci ci ci ci 65 test 73 i/m gnd
peb 20320 application notes user ? s manual 208 01.2000 figure 103 its08301 vg96 j2a 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 23 24 24 25 25 26 26 27 27 28 28 29 29 30 30 31 31 32 32 u3 ce 46 pcsq2 22 rd frdq 25 frdq wr 5 intq2 aint 36 acknl 2 u2a 74hc04 r 2 1k ? cc v d1 led red 1 3 jp 22 33 11 ? k 4.7 3 r cc v 18 a adr0 1 adr a 19 2 adr a 20 3 adr a 21 0 1 2 3 27 4 34 33 8 rdo cos rdo xdi roid xoid rsigm 39 xsigm 40 rchpy 6 v cc r 4 10 k ? 37 xchpy ad0 9 d0 1 d 10 1 2 d 11 2 3 d 12 3 4 d 13 4 5 d 14 5 6 d 15 6 7 d 16 7 acfa clk 1 gnd 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 oe 11 u10 gal16v8 1 o 19 18 o2 17 o3 16 o4 15 o5 14 o6 13 o7 12 o8 loop rstq rdo ad0 ad1 ad2 ad4 ad5 pcsq2 g0 g1 g2 g4 g5 gxdi g6 adr0 adr1 adr2 adr3 30 31 36 37 38 39 40 4 32 28 29 1 3 2 jp4 fsc clk2m clk4mq xclk clk2mq xtom 3 xtop 44 xdom 43 xdop 42 rdim 31 rdip 30 xrclk 41 rrclk 29 sclk 28 7 32 35 rfsp syp res d2 1n4148 u2b green led d3 34 c 15 47 nf gnd 6 r k ? 1 74hc04 1 ? m r 5 cc v gnd gxdi cos 7 ad ad ad ad ad ad ad xdi
peb 20320 application notes user ? s manual 209 01.2000 figure 104 its08302 pcsq2 g0 g1 g2 g4 g5 gxdi g6 4 ad 3 ad 1 ad 0 ad 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 j2c vg96 ad5 ad6 ad7 6 fsc 7 fsc xdin 30 31 xdip rdop 36 37 rdon rclk 38 39 clk2m 40 clk2m 4 clk4m 5 clk4m 16 clk12m 15 clk16m 32 xclk 28 xtin 29 xtip u4 fscq fsc clk2m clk4mq xclk clk2mq pract pf 12 17 c c 18 12 pf x2 16 c c 19 23 c c 20 pf 10 22 c c 21 10 pf 33 9 10 12 13 43 11 14 26 3 27 17 cs xtal xtal xtal xtal 4 3 2 1 ls ls lr ll mode jatt sync ls 8 0 2 1 2.2 ? k r v cc lp cos jatt mode 4 ad 2 ad 1 ad 0 ad wrq pcsq3 rstq 8 o 12 7 o 13 6 o 14 5 o 15 4 o 16 3 o 17 2 o 18 19 o1 gal16v8 u9 11 oe 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 gnd 1 clk 3 ad pclk3 loop 2.2 k ? r 15 cc v 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 gnd cc v vg96 j2b rstq intq2 pcsq4 pcsq3 pcsq2 wrq frdq xdi rdo sync clk2m clk2mq clk4mq fsc fscq xclk clk33_con gnd 35 41 23 22 ssd v v ssr ssx v v ssx 47 nf c 24 ddx v v ddx ddr v v ddd 18 19 42 34 dd2 v 1 25 c 47 cc v r k ? 60 11 11 60 ? k r nf 100 26 c cc v gnd gnd cc v d10 d11 v cc gnd 8 15 ? k r r k ? 15 7 d8 d9 d5 d4 gnd cc v d6 v cc gnd d7 1 2 xl xl rl rl 2 1 20 24 44 2 3 8 6 5 5 6 8 3 u6 u5 9 1 ? k r r k ? 1 14 f6 so5k130 gnd 1 2 1 2 lout1 lin1 2 1 2 1 gnd so5k130 f5 13 1 ? k r r k ? 1 12 lout2 lin2 f1 a81_c90x f3 a81_c90x a81_c90x f2 a81_c90x f4 zkb_402/512 zkb_402/512 nf 100 31 c c 30 100 nf nf 100 29 c nf 100 28 c gnd cc v g0 1 g 2 g 6 g g g5 4 jatt sync mode 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 pclk3 ad2 f 16 mhz mhz 12 x1 gnd 1 10 10 1
peb 20320 application notes user ? s manual 210 01.2000 figure 105 its08303 14 d0 1 d 15 2 d 16 3 d 17 4 d 18 5 d 19 6 d 20 7 d 21 8 d 25 9 d 26 10 d 27 11 d 28 12 d 29 13 d 30 14 d 31 15 d 32 16 d 35 17 d 36 18 d 37 19 d 38 20 d 39 21 d 40 22 d 41 23 d 42 24 d 43 25 d 46 26 d 47 27 d 48 28 d 50 29 d 51 30 d 52 31 d 53 114 0 be be 1 113 be 2 112 be 3 109 a 108 2 3 a 107 4 a 106 5 a 105 6 a 104 7 a 103 8 a 102 9 a 101 10 a 97 11 a 96 12 a 95 13 a 94 14 a 93 15 a 92 16 a 91 17 a 90 18 a 87 19 a 85 20 a 84 21 a 83 22 a 82 23 a 81 24 a 80 25 a 79 26 a 76 27 a 74 28 a 73 29 a 72 30 a 71 31 a 70 u 18 1 1 16 1 14 1 12 2 9 2 7 2 5 2 3 y y y y y y y y1 2 3 4 1 2 3 4 1 a 1 1a 2 1a 3 1a 4 2a1 2a2 2a3 2a4 u clk33 tsp_out pclk3 tclk_out clk33_con 74hct244 1g 2g 19 1 17 15 13 phi 8 33 mhz gnd tclk_in tsp_in oszi 11 8 6 4 2 data cc v 124 65 129 130 9 123 118 69 ads le/be bs rdy hold hlda reset clk2 16 3 port 125 int/int 119 ca 3.3 k ? gnd v cc 2.7 k ? 82596dx rdtq adsq hold rlda l_reset portq ca muintq gnd 57 rts cts txc 64 txd 54 rxc 59 rxd 60 crs 63 cdt 61 62 v cc 115 breq gnd resistor r 126 120 58 lock w/r lpbk 16 1 2 15 3 14 4 13 5 12 6 11 7 10 8 9 rp1 4.7 k ? rdtq mu_bgoq l_lockq cpurstq lan_w_rq adsq hold ? k 2.7 2 rp 9 8 10 7 11 6 12 5 13 4 14 3 15 2 1 16 gnd gnd 1 2 3 4 5 6 7 8 9 4.7 ? k ser_int l_lockq lan_w_rq addr be rapack v cc cc v
peb 20320 application notes user ? s manual 211 01.2000 figure 106 its08310 8 o 12 7 o 13 6 o 14 5 o 15 4 o 16 3 o 17 2 o 18 19 o1 gal16v8a reset 11 oe 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 gnd 1 clk muclk cpurstq l_reset portq cpurstq muclk clk 1 gnd 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 oe 11 port gal16v8a 1 o 19 18 o2 17 o3 16 o4 15 o5 14 o6 13 o7 12 o8 ca m32_arq dtoeq lan_csq r_wq m32_arq clk33 gnd clk33 hldain tsq r_wq 8 o 12 7 o 13 6 o 14 5 o 15 4 o 16 3 o 17 2 o 18 19 o1 gal16v8a signal 11 oe 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 gnd 1 clk taq rdyq adsq lan_w_rq hold mu_brq brq ml_bgq clk 1 gnd 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 oe 11 arbiter gal16v8a 1 o 19 18 o2 17 o3 16 o4 15 o5 14 o6 13 o7 12 o8 bgackq hldain muclk clk33 2 mu_bgackq cpurstq mu_bgq m32_csq a4 ml_bgq mu_bgackq lan_csq siz1 8 o 12 7 o 13 6 o 14 5 o 15 4 o 16 3 o 17 2 o 18 19 o1 gal16v8a address 11 oe 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 gnd 1 clk a0 pcsq5 a1 siz0 be beq0 beq1 beq2 beq3
peb 20320 application notes user ? s manual 212 01.2000 figure 107 its08311 j1c 65 d0 1 2 d 66 3 d 67 4 d 68 5 d 69 6 d 70 7 d 71 8 d 72 9 d 73 10 d 74 11 d 75 12 d 76 13 d 77 14 d 78 15 d 79 16 d 80 17 d 81 18 d 82 19 d 83 20 d 84 21 d 85 22 d 86 23 d 87 24 d 88 25 d 89 26 d 90 27 d 91 28 d 92 29 d 93 30 d 94 31 d 95 32 d 96 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 data vg96 vg96 address 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 a j1a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a 1 vg96 64 32 63 31 62 30 61 29 60 28 59 27 58 26 57 25 56 24 55 23 54 22 53 21 52 20 51 19 50 18 49 17 48 16 47 15 46 14 45 13 44 12 43 11 42 10 41 9 40 8 39 7 38 6 37 5 36 4 35 3 34 2 1 33 j1b pclk3 dtoeq taq muintq0 cpurstq muintq gnd cc v pcsq5 w_rq bgackq ml_bgq lockq bgq_68 tsq bclk bbq muclk
peb 20320 application notes user ? s manual 213 01.2000 figure 108 its08312 17 txd txd txcq txc 16 rtsq ten 15 6 crs crsq 8 rxc rxcq rxd rxd 9 cdtq cdt 7 enetv1 1 2 noor cap c lpbkq 3 lpbk/wdtd serint clsn 12 11 clsn rcv 4 rcv 5 18 trmt 19 trmt 1 2 3 cd+ cd- rx+ tx- tx+ rx- 6 5 4 u u 82c50tad em2 gnd gnd 13 14 y c 30 pf pf 30 c 20 mhz cds 20 18 rxi 17 txo jp 13 2 gnd 16 11 cc v jumper3x1 hbe dm c 0.01 f 1m ? r ee v gnd 12 o4 r 150 ? d led yellow u t21 5 b 4 a2 a1 3 9 rin 11 rext/cext r 40 k ? 10 cext c k105 cc v x1 x2 q 6 1 q led green d d led red q 6 1 q k105 c cext 10 r rext/cext 11 rin 9 3 a1 a2 4 b 5 t21 u r 150 ? r 150 ? ua cc v 40 k ? v cc gnd 12 gnd gnd j bnc r ? 78 78 ? r 240 ? r 240 ? r
peb 20320 application notes user ? s manual 214 01.2000 5.3 memory bus occupancy for a single munich32 the munich32 may be used in different system architectures depending mainly on how the data buffers are shared between the interacting bus masters. in the following the memory bus occupancy is calculated for a system, where the munich32 is directly coupled with a 32-bit cpu (compatible to either motorola 68020 or intel 386) sharing one common local cpu bus and translated via an appropriate system bus controller sharing the system memory as well. this example system looks very similar to the one depicted in the figure 7 and figure 9 of chapter 1 . in this case it is easier to estimate the behavior of the complete system. in addition to that, the following assumptions are made about the communication parameters: ? hdlc operating mode ? the munich is clocked with sclk = 16 mhz ? the bus arbitration time is estimated to be about 4 extra clock cycles (sclk) for every 10 munich32 memory accesses (typical is 10 to 16) ? the data buffer size allocated in the data buffer pool is 32 bytes for transmit and receive descriptors ? a full duplex connection with up to 32 64 kbit/s channels and heavy traffic load (shared flags) ? the data size per hdlc frame is defined to be without the shared flag and the two crc bytes ? when the data size exceeds 32 bytes, more than one descriptor is needed for a single frame ? an interrupt information is generated for every descriptor. the munich32 needs the following 32-bit memory accesses (read or write): receive: read descriptor 3 write current descriptor address 1 write status 1 write interrupt 1 write data (size) accesses size 11 12 13 14 25 ::
peb 20320 application notes user ? s manual 215 01.2000 transmit: read descriptor 3 write current descriptor address 1 write interrupt 1 read data (size) accesses size 11 12 13 14 25 :: the accumulated access time for a single munich32 channel, depending on the actual frame size, is then related to the serial transfer time on a pcm system: (3 + size) 125 s. the following two diagrams illustrate the overall results for two different ranges and their corresponding resolution. as you can see, for frame size greater than 32 bytes the time needed for munich32 memory accesses drops below 5%. that means in a simple communication subsystem (e.g. primary access board) the cpu performance is also reduced by 5% only and it is therefore not necessary to use a complex multiport memory approach to reach a significant overall performance gain. figure 109 frame size 1 to 512 itd04696 0 1 5 10 15 20 25 32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512 % number of data bytes ch=32 ch=30 ch= 1 memory bus occuppancy
peb 20320 application notes user ? s manual 216 01.2000 figure 110 frame size 1 to 32 0 1 5 10 15 20 25 % 29 30 31 32 27 28 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 memory bus occuppancy number of data bytes itd04697 ch= 1 ch=30 ch=32
peb 20320 application notes user ? s manual 217 01.2000 5.3.1 bus occupancy calculations as described in the previous section, the munich32 in a steady state condition consumes approximately 5% of the system bus bandwidth. based on the conditions previously described, a set of equations can be used to describe the munich32 system bus behavior. other munich32 systems can be evaluated using these equations. the bus occupancy is defined as the ratio of the time required for memory accesses for that data to the time used to send the data. the two equations are defines as follows: time used for memory accesses: = number of received bits plus transmitted bits multiplied by the time required to transfer this information to/from memory. ={([6+(1+ m )] rc ) + (5 + (1 + m )] tc )} (1 + 1/ ba ) nc sclk 6 for receive descriptor access 5 for transmit descriptor access (1 + m ) for data access where m is the largest integer smaller ( n ? 1)/4 ( n is the number of transmitted data bytes). rc is the number of receive channels. tc is the number of transmit channels. (1 + 1/ ba ) is the bus arbitration time sclk is the system clock (61 ns for 16.384 mhz) nc is the number of memory clocks per bus operation (0ws = 4, 1ws = 5, etc.). time used to send the data is the number of transmitted bits per time slot multiplied by the frame time: = ((4 + n ) 8/ abtc ) 125 s 4 because shared flags are not used + 2 byte crc n is the number of octets to transmit abtc = assigned bits to channel e.g. a channel with one time slot of 1 bit would require 8/1 = 8 time slots to transmit a single octet. from the previous example, the variables are assigned the following values: variable n m rc tc (1 + 1/ba) sclk nc abtc value 32 bytes 7 32 32 1.1 61 ns 4 8
peb 20320 application notes user ? s manual 218 01.2000 applying these values to the equations yields the following: time used to access memory = {([6 + (1 + 7)] 32) + ([5 + (1 + 7)] 32)} (1.1) 4 61 ns = {(14 32) + (13 32)} 1.1 244 ns = {864} 268.4 ns = 231.9 s. time used to send data = ((4 + 32) 8/8) 125 s. = 36 125 s. = 4500 s. bus occupancy = 231.9 s/4500 s = 5.1% when the packet size is much larger (256 bytes or larger), the bus occupancy decreases to less than 4%. conversely, sending very small frames (4 bytes), causes bus occupancy to increase to over 11%. this is primarily due to the increased descriptor processing per packet. 5.3.2 bus occupancy for idle tx channels the previous discussion shows bus occupancy to be very low, even when a munich32 is processing 32 channels of receive and transmit data. there is another system consideration of bus occupancy that must be examined. when a munich32 channel has no data required for transmit, the channel must be temporarily (or permanently) stopped. there are several methods that may be used to stop the transmission. 1. the first method involves executing a channel command with th = 1 (reactivation of the channel requires a new channel command with th = 0). this method places the transmit channel on hold and prevents any further accesses of the memory for this channel. 2. a second method is based on statistical knowledge of the frequency of transmitted frames. if frames are transmitted without shared flags and if the average number of interframe time fill characters can be determined, the munich32 can be programmed to suppress poll sequences. by setting fnum in the tx descriptor to a value (n) greater than 0, the munich32 will transmit n + 1 idle characters after the end of the current frame. during this period of interframe time fill, the munich32 will not poll the tx descriptor. as an example, if it is determined that 5 idle characters typically occur between frames, fnum can be set to 4. at the end of the current frame, 5 idle characters will be transmitted (625 s. on a ds0 channel) before the next frame is transmitted and no polls of the tx descriptor will occur during that time.
peb 20320 application notes user ? s manual 219 01.2000 3. the final method is to set the hold bit in the tx descriptor. when the hold bit in the tx descriptor is set, the munich32 checks the status of the this bit for each time slot assigned to this channel. in this way, if the bit has been cleared, the munich32 will immediately resume transmission. although this method is simpler (in concept) for the software design, it causes the munich32 to consume higher than normal bus bandwidth. for this reason, this is the least desirable of the three methods. in the previous example discussed, if all 32 channels were holding on the tx descriptors, bus occupancy might rise as high as 17%. the reason bus occupancy rises this dramatically is due to the bus access once per time slot rather than once every four time slots (typical).
peb 20320 application hints user ? s manual 220 01.2000 6 application hints 6.1 frequency adaption in an intel 368 common bus system if you use the i386 as host processor with the munich32 in a common bus system you have to adapt the different frequencies of the devices. the munich32 works e.g. with a fixed frequency of 16.384 mhz in cept 32 channel pcm highway format. the i386 works with frequencies from 16 up to more than 50 mhz. if you compare the timing diagrams you will see that a few glue logic is necessary to adapt the munich32 to the i386 timing. a possible adaption of the different frequencies is described below. for an example we use an i386 with a frequency of 16.384 mhz. the munich32 is configured in the cept 32 channel pcm highway format with a sclk of 16.384 mhz. the sclk signal is build by dividing the 32.768 mhz clk2 signal of the i386. that means that both clocks are synchronous. this is not necessary in general but selected in our example. the bus controller generates e.g. one wait state for the memory access. the falling edge of the ads signal marks the beginning of a bus cycle which is completed with the sampled ready signal. a general bus controller should not see a difference between the two bus masters, so we have to delay the falling edge of the munich32 ads signal to that moment as the i386 would generate its ads to get the ready signal at the same time. in the picture below you can see the relationship and the adaption of both timings as specified in our example. a second picture shows the adaption in an i386 24.576 mhz system. again the clocks are synchronous.
peb 20320 application hints user ? s manual 221 01.2000 figure 111 itd04556 sclk ads ready clk clk2 ads ready s1 s2 munich32 sclk=16.384 mhz t1 delay i386, 16.384 =>clk2=2xsclk mhz t1 t2 t2 t1
peb 20320 application hints user ? s manual 222 01.2000 figure 112 itd04557 sclk ads ready clk clk2 ads ready s1 s2 munich32 sclk=16.384 mhz t1 delay i386, 24.576 =>clk2=3xsclk mhz t1 t1 t1 t2 t2 t1
peb 20320 application hints user ? s manual 223 01.2000 6.2 munich32 memory space requirement implementation independent: ? start address 4 byte ? control & configuration section 908 byte ? tx descriptor size 12 byte ? rc descriptor size 16 byte implementation dependent: ? interrupt queue size 64 byte < interrupt queue size < 16384 byte ? data buffer size data buffer size ? allocation of tx and rc descriptors per channel in general the memory space requirement may be calculated the following way: start address + size of control & configuration section + interrupt queue size + number of channels [number of tx descriptors (tx descriptor size + data buffer size)] + number of channels [number of rc descriptors (rc descriptor size + data buffer size)] ????????????????????????????????????????????? = total munich32 memory space requirement example: the munich32 is used in a 31 channel isdn primary access application, that means that 31 full duplex channels are active. the lapd protocol is implemented. in this case a window size of 7 is specified, that means that 7 rc descriptors and in transmit direction 7 tx descriptors must be available for each channel. the data buffer size is set to 260 byte according to the lapd specification. summary: ? 31 channels; ? interrupt queue size = 1024 byte; ? 7 tx and 7 rc descriptors; ? data buffer size = 260 byte; in our example a memory space of 120 kbytes is required.
peb 20320 application hints user ? s manual 224 01.2000 6.3 serial interface to different pcm systems the serial interface of the munich32 is very general and comprises standard clock, pcm frame synchronization and data signals, which are independent for both directions. the following description explains typical applications integrating the munich32 into 2.048 mbps pcm systems, like siemens system interface for primary access and the mitel st bus. in these systems the receive and transmit clocks are identical. the general timing is shown in figure 113 (see also chapter 2.1 ). figure 113 the rsp pulse is shifted by one clock period against the tsp pulse. the main task using this timing for different pcm systems is to adapt the tsp and rsp pulses appropriately, as described below. 6.3.1 munich32 for siemens primary access interface the siemens devices for the primary access interface is the frame and line interface component (falc54). this device can directly be connected to the munich32 without any additional glue logic. in combination with the munich32 this application is the most effective way to build a powerful and flexible primary access interface, especially supporting different combined b channel paths over long distances (lan-wan internetworking). the following block diagram illustrates how easy it is to integrate the munich32 into a primary access application based on siemens devices. itd04694 time-slot 0 time-slot 0 rclk=tclk tsp rsp tdata rdata
peb 20320 application hints user ? s manual 225 01.2000 figure 114 the adaption of the tsp and rsp pulses is solved by means of shifting the receive data and transmit data in the falc54 device appropriately. in this case the tsp and rsp synchronization pulses are also identical. the falc54 device contains special registers to control the bit shift of the serial bit streams at the system interface (see falc54 data sheet). with the following register programming the bit shift selected is t = 509 for the munich32 transmit data and t = ? 1 for the receive data respectively. the programming is as follows: xdi: xc1.xto = 3d h => x = 494 => t = 509 xc0.xco = 06 h rdo: rc1.rto = 00 h => x = 5 => t = ? 1 rc0.rco = 05 h its07370 tclk tsp tdata rdata rsp rclk xdi rdo clk8m clkx munich32 peb 20320 2254 peb falc54 sclkx sypxq sclkr syprq fsc fscq
peb 20320 application hints user ? s manual 226 01.2000 the timing in principle is depicted in the following diagram. without all details of a typical electrical timing it illustrates how the different signals from munich32, and falc54 are mapped in such a primary access system. figure 115 itd08282 fsc=tsp=rsp clkx=rclk=tclk tdata =xdi rdata =rdo (t=509) (t=-1) = : invalid area channel 0, bit 0 (least significant bit) : =
peb 20320 application hints user ? s manual 227 01.2000 6.3.2 munich32 in systems with mitel st bus a few more effort is necessary to integrate the munich32 into a st bus system from mitel. the basic assumption made here is that the clock master is the st bus system. that means all signals derived from the st bus need to be adapted to match the munich32 timing requirements. first of all the clock signal c2 must be inverted before it can be used as the munich32 clocks (tclk = rclk = c2 ). the next step is the generation of the tsp and rsp pulses out of the f0 signal, which is the st bus frame synchronization signal. the rsp pulse can be derived from the f0 signal by means of a simple d-flip-flop clocked with c2, as depicted in the following figure 116 . due to the necessary phase relationship between the serial data streams and their corresponding tsp, rsp and f0 pulses, the effort to generate the tsp pulse is much higher than for rsp. figure 116 its04692 tclk tsp tdata rdata rsp rclk st-bus sti sto munich32 peb 20320 c2 f0 & q q d res 8-bit counter d q q system clock adaption decode ? 254 ?
peb 20320 application hints user ? s manual 228 01.2000 the tsp pulse must be derived from the f0 signal with a phase shift by 255 clock cycles to be at the right position. the corresponding timing is illustrated in the following diagram. figure 117 itd04693 c2 f0 tsp rclk=tclk=c2 tdata =sti rdata =sto = : invalid area channel 0, bit 0 (least significant bit) : = derived from f0 and synchronized by means of c2 *) rsp *) *)
peb 20320 electrical characteristics user ? s manual 229 01.2000 7 electrical characteristics note: all specifications are for v3.4 unless otherwise specified. version numbers are identified in the interrupt information bits vn(3:1): these bits are ? 0000 ? for version 1.1 ? 0001 ? for version 2.1 ? 0010 ? for version 2.2 ? 0100 ? for version 3.2 ? 0110 ? for version 3.4 7.1 absolute maximum ratings note: stresses above those listed here may cause permanent damage to the device. exposure to absolute maximum rating conditions for extended periods may affect device reliability. table 12 parameter symbol limit values unit min. max. ambient temperature under bias: peb pef t a t a 0 ? 40 70 85 c storage temperature t stg ? 65 125 c voltage at any pin with respect to ground v s ? 0.4 v dd + 0.4 v
peb 20320 electrical characteristics user ? s manual 230 01.2000 7.2 dc characteristics note: the listed characteristics are ensured over the operating range of the integrated circuit. typical characteristics specify mean values expected over the production spread. if not otherwise specified, typical characteristics apply at t a =25 c and the given supply voltage. table 13 t a = 0 to + 70 c; v dd = 5 v 5%, v ss = 0 v parameter symbol limit values unit test condition min. max. l-input voltage v il ? 0.4 0.8 v ? h-input voltage v ih 2.0 v dd + 0.4 v ? l-output voltage v ql ? 0.45 v i ql = 7 ma (pin tdata) i ql = 2 ma (all others) h-output voltage h-output voltage v qh v qh v dd ? 0.5 2.4 ? v v i qh = ? 2 ma (pin hold/br) i qh = ? 100 a (all others) i qh = ? 400 a power supply current operational i cc ? < 100 ma v dd = 5 v inputs at 0 v/ v dd , no outputs loads power down (no clocks) i cc ? < 2 ma input leakage current output leakage current i li i lq ? 10 a0 v < v in < v dd to 0 v 0 v < v out < v dd to 0 v
peb 20320 electrical characteristics user ? s manual 231 01.2000 7.3 capacitances 7.4 ac characteristics t a = 0 to + 70 c; v dd = 5 v 5% inputs are driven to 2.4 v for a logical ? 1 ? and to 0.4 v for a logical ? 0 ? . timing measurements are made at 2.0 v for a logical ? 1 ? and at 0.8 v for a logical ? 0 ? . the ac testing input/output waveforms are shown below. figure 118 input/output waveform for ac tests table 14 t a = 25 c; v dd = 5 v 5%, v ss = 0 v parameter symbol limit values unit test condition min. max. input capacitance c in 510pf ? output capacitance c out 815pf ? i/o-capacitance c io 10 20 pf ? its00621 = 150 load c test under device 0.45 2.4 2.0 0.8 0.8 2.0 test points pf
peb 20320 electrical characteristics user ? s manual 232 01.2000 7.5 microprocessor interface intel bus mode figure 119 timing diagram intel bus mode itd03510 1 sclk a31-a2 be(3:0), ads ready 2 d31-d0 3 3 4 5 8 (read cycle) (write cycle) d31-d0 berr s1 s2 s1 10 9 7 6 pchk [dp(3:0)] [dp(3:0)] 11 11
peb 20320 electrical characteristics user ? s manual 233 01.2000 figure 120 bus arbitration timing diagram intel bus mode intel bus timing table 15 no. parameter limit values unit min. max. 1 address, valid delay ? 20 ns 2 be, int, w/r valid delay ? 20 ns 3ads valid delay ? 20 ns 4 ready setup time 10 ? ns 5 ready hold time 5 ? ns 6 berr setup time 10 ? ns 7 berr hold time 5 ? ns 8 data valid delay (write) ? 35 ns 9 data setup time (read) 5 ? ns 10 data hold time (read) 8 ? ns itd03511 12 12 13 13 14 15 16 17 high z high z sclk hold hldao hlda microprocessor interface 11 pchk
peb 20320 electrical characteristics user ? s manual 234 01.2000 11 parity check valid delay ? 50 ns 12 hold valid delay ? 20 ns 13 hldao valid delay ? 20 ns 14 hlda setup time 10 ? ns 15 hlda hold time 10 ? ns 16 microprocessor interface (mi) driven after hlda set 2 sclk cycles ?? 17 mi tristated after bus accesses ? 40 ns table 15 no. parameter limit values unit min. max.
peb 20320 electrical characteristics user ? s manual 235 01.2000 7.6 microprocessor interface motorola bus mode figure 121 timing diagram motorola bus mode itd03513 18 20 sclk a31-a2 int, be (3:0), r/w as dsack d31-d0 19 21 21 23 22 24 25 (read cycle) (write cycle) d31-d0 berr ds t1 t2 t3 t4 t1 28 29 19 26 27
peb 20320 electrical characteristics user ? s manual 236 01.2000 figure 122 bus arbitration timing motorola bus mode motorola bus timing table 16 no. parameter limit values unit min. max. 18 address, be, int, r/w valid delay ? 20 ns 19 as , ds asserted after clock low ? 20 ns 20 as , ds negated after clock low ? 20 ns 21 dsack , berr setup time to clock low 5 ? ns 22 data read setup time to clock low 5 ? ns 23 data read hold time to clock low 8 ? ns itd03514 30 33 32 33 sclk br bg bgack microprocessor interface 30 31 35 36 34 bgo sclk br bg bgo 36 36
peb 20320 electrical characteristics user ? s manual 237 01.2000 24 data write valid delay ? 35 ns 25 data write hold from clock high ? 35 ns 26 address valid to as high 10 ? ns 27 data valid to ds low 10 ? ns 28 ds high to data invalid 5 ? ns 29 as high to address invalid 10 ? ns 30 br valid delay ? 25 ns 31 bg setup time to clock high 5 ? ns 32 bg hold time after bgack 10 ? ns 33 bgack valid delay ? 25 ns 34 microprocessor interface driven after bgack asserted 1 sclk cycle ?? 35 clock high to microprocessor interface tristated ? 40 ns 36 bgo valid delay from clock high ? 40 ns 1) newly specified for v2.1 and v2.2. not specified in data sheet 08.93. table 16 no. parameter limit values unit min. max.
peb 20320 electrical characteristics user ? s manual 238 01.2000 serial interface timing figure 123 table 17 no. parameter limit values unit min. max. 37 receive strobe guard time 10 ? ns 38 receive strobe setup 5 ? ns 39 receive strobe hold 5 ? ns 40 receive data setup 5 ? ns 41 receive data hold 5 ? ns rsp rdata 39 37 42 38 43 40 41 rclk tclk 48 47 50 45 49 44 46 tdata tsp itd03515
peb 20320 electrical characteristics user ? s manual 239 01.2000 note: 1. the frequency on the serial line must be smaller or equal to 1 / 8 th of the frequency on the p bus for 1.536 mhz, 1.544 mhz, 2.048 mhz 1 / 4 th of the frequency on the p bus for 4.096 mhz. 2. for complete internal or complete external loop t 42 and t 49 must be greater or equal to 3 times t 51 . clock input timing figure 124 clock timing 42 receive clock high width 60 ? ns 43 receive clock low width 60 ? ns 44 transmit strobe guard time 20 ? ns 45 transmit strobe setup 5 ? ns 46 transmit strobe hold 5 ? ns 47 transmit data delay ? 40 ns 48 transmit clock to high impedance ? 50 ns 49 transmit clock high width 60 ? ns 50 transmit clock low width 60 ? ns table 17 (cont ? d) no. parameter limit values unit min. max. 53 52 sclk itd03516 51
peb 20320 electrical characteristics user ? s manual 240 01.2000 note: if f t is the frequency of the clock tclk, f r the frequency of the clock rclk and f s the frequency of the clock sclk the equations 7.996 max ( f t , f r ) f s 16.667 mhz for cept, t1, e1 pcm mode and 3.998 max ( f t , f r ) f s 16.667 mhz for 4.096 mhz pcm mode describe the allowed range of frequencies for f s . system interface timing figure 125 after power up a logical ? 1 ? at the reset pin of the munich v3.4 sets the device into a reset state where the complete microprocessor bus interface is tristated and the internal reset sequence is started. table 18 no. parameter limit values unit min. max 51 cycle period 50 ? ns 52 clock low time 25 ? ns 53 clock high time 25 ? ns table 19 no. parameter limit values unit min. max. 55 reset to first action request delay 12 sclk cycles ?? 56 ar# pulse width 2 sclk cycles 5 sclk cycles ? 57 reset pulse width 2 sclk cycles ?? 57 reset ar 56 itt10668 55 after reset request ar first action
peb 20320 electrical characteristics user ? s manual 241 01.2000 the trailing edge of the reset starts the last part of the internal reset sequence and takes about 12 sclk cycles. it is not allowed to give an action request (ar) during these first 12 sclk cycles after the trailing edge of signal reset. jtag-boundary scan timing figure 126 jtag-boundary scan timing table 20 intel bus timing no. parameter limit values unit min. max. 58 jtest0 (tck) period 166 inf ? 59 jtest0 (tck) high time 80 ?? 60 jtest0 (tck) low time 80 ?? 61 jtest1 (tms) setup time 15 ?? 62 jtest1 (tms) hold time 10 ?? 63 jtest2 (tdi) setup time 15 ?? 64 jtest2 (tdi) hold time 15 ?? 65 jtest3 (tdo) valid delay 30 ?? itd03512 jtest0 (tck) jtest1 (tms) jtest2 (tdi) jtest3 (tdo) 65 62 61 59 60 63 64 58
peb 20320 package outlines user ? s manual 242 01.2000 8 package outlines gpm05247 p-mqfp-160-1 (plastic metric quad flat package) sorts of packing package outlines for tubes, trays etc. are contained in our data book ? package information ? . dimensions in mm smd = surface mounted device
peb 20320 appendix user ? s manual 243 01.2000 9 appendix 9.1 source code extract munich32 the munich32 code extract is taken from the low level device driver for the munich32, which is written in ? c ? . this extract gives you a brief impression how a munich32 device driver could be programmed. the munich control configuration (munichctrlcfg) is a structure which consists of the following substructures: action specification actionspec interrupt queue specification intqueuespec time-slot assignment timeslot[ ] channel specification channelspec[ ] munich receive descriptor pointer currrcdescraddr[ ] munich transmit descriptor pointer currtxdescraddr[ ] these substructures mainly consist of bit fields. the use of bit fields does not produce a speed optimized but a highly readable code, in our case to demonstrate the programming of the munich32 very clearly. the structures are directly memory mapped to the munich32 structures and listed below. in this short example we select the cept-32 pcm highway format and the hdlc mode. all time-slots are assigned to channel number 0. hdlc frames are send via channel0. there are two functions: initchannel0andsendfirstframe() txhdlcframe(). the function initchannel0andsendfirstframe() comprises the following initialization tasks: ? the munich32 is configured for the cept32 channel format ? the interrupt queue is initialized and assigned ? each time-slot consists of 8 bit and all time-slots are assigned to channel 0 ? the transmit outputs and the receive inputs are active ? here nine transmit buffers are assigned to channel0 ? idle code flags.
peb 20320 appendix user ? s manual 244 01.2000 the second part of the function prepares the device to send the first hdlc frame: ? the linked list of frames to be send is registered ? in receive direction a linked list of 10 receive descriptors with 32 bytes data each is prepared and installed. ? the macro munich32_action_request() ? generates ? an activation request pulse to the munich32 ? the device reads the initialization data and transmits the first transmit frame the munich32 then polls the hold bit of last transmit descriptor until this bit is cleared. if the hold bit is cleared the device sends the next data until it finds the next hold bit. the function txhdlcframe connects the transmit descriptor of the next frame with the last transmit descriptor of the last send frame and clears the hold bit; the next frame is send.
peb 20320 appendix user ? s manual 245 01.2000 9.2 source code ? /*-------------------------------------------------------------------------- - munich32 transmit descriptor structure - -------------------------------------------------------------------------- */ typedef struct munichtxdescr { unsigned fnum : 11; unsigned csm : 1; unsigned : 3; unsigned v110 : 1; unsigned no : 13; unsigned hi : 1; unsigned hold : 1; unsigned fe : 1; word8 _ptr data; struct munichtxdescr _ptr next; } munich_transmit_descriptor; typedef munich_transmit_descriptor _ptr munich_tx_descr_ptr /*-------------------------------------------------------------------------- - munich32 receive descriptor structure - -------------------------------------------------------------------------- */ typedef struct munichrcdescr { unsigned : 16; unsigned no : 13; unsigned hi : 1; unsigned hold : 1; unsigned : 1; unsigned : 8; unsigned status : 8; unsigned bno : 13; unsigned : 1; unsigned c : 1; unsigned fe : 1; word8 _ptr data; struct munichrcdescr _ptr next; } munich_receive_descriptor;
peb 20320 appendix user ? s manual 246 01.2000 typedef munich_receive_descriptor _ptr munich_rc_descr_ptr; /*-------------------------------------------------------------------------- - munich32 structures - -------------------------------------------------------------------------- */ typedef struct { unsigned channelnumber : 5; unsigned rt : 1; unsigned : 2; unsigned fo : 1; unsigned err : 1; unsigned sf : 1; unsigned ifc : 1; unsigned fi : 1; unsigned hi : 1; unsigned arf : 1; unsigned arack : 1; unsigned x : 1; unsigned sa : 1; unsigned sb : 1; unsigned e1 : 1; unsigned e2 : 1; unsigned e3 : 1; unsigned e4 : 1; unsigned e5 : 1; unsigned e6 : 1; unsigned e7 : 1; unsigned frc : 1; unsigned : 4; unsigned intflag : 1; } munich32_interrupt_queue; typedef struct { munich32_interrupt_queue _ptr addr; unsigned n : 8; unsigned : 24; } interrupt_queue_specification; typedef struct { unsigned rcfillmask : 8; unsigned rcchannelnumber : 5;
peb 20320 appendix user ? s manual 247 01.2000 unsigned rti : 1; unsigned : 2; unsigned txfillmask : 8; unsigned txchannelnumber : 5; unsigned tti : 1; unsigned : 2; } time_slot_assignment; typedef struct { unsigned iftf : 1; unsigned mode : 2; unsigned fa : 1; unsigned trv : 2; unsigned crc : 1; unsigned inv : 1; unsigned tflagcs : 1; unsigned tflag : 7; unsigned ra : 1; unsigned ro : 1; unsigned th : 1; unsigned ta : 1; unsigned to : 1; unsigned ti : 1; unsigned ri : 1; unsigned nitbs : 1; unsigned intmask : 8; munich_rc_descr_ptr frda; munich_tx_descr_ptr ftda; unsigned itbs : 6; unsigned : 26; } channel_specification; typedef struct { word32 *currentreceivedescriptoraddrch; } current_rc_descr_addr; typedef struct { word32 *currenttransmitdescriptoraddrch; } current_tx_descr_addr;
peb 20320 appendix user ? s manual 248 01.2000 typedef struct { unsigned : 2; unsigned ia : 1; unsigned loopi : 1; unsigned loop : 1; unsigned loc : 1; unsigned res : 1; unsigned im : 1; unsigned channelnumber : 5; unsigned : 1; unsigned ico : 1; unsigned in : 1; unsigned mfl : 13; unsigned pcm : 3; } action_specification; /*-------------------------------------------------------------------------- - munich32 control block - -------------------------------------------------------------------------- */ typedef struct { action_specification actionspec; interrupt_queue_specification intqueuespec; time_slot_assignment timeslot 32; channel_specification channelspec 32; munich_rc_descr_ptr currrcdescraddr 32; munich_tx_descr_ptr currtxdescraddr 32; } munich32_ctrl_cfg_section; .. ..
peb 20320 appendix user ? s manual 249 01.2000 /*-------------------------------------------------------------------------- - function : initchannel0andsendfirstframe - -------------------------------------------------------------------------- - description : initialization of channel 0. - - - pcm highway format cept 32-channel - - - hdlc mode - - - all timeslots are assigned to channel 0. - - - send the first hdlc frame - -------------------------------------------------------------------------*/ static void initchannel0andsendfirstframe ( munich_tx_descr_ptr m32txdescr ) { .. .. /* ------------------------------------------------------------------------- */ txdescr = m32txdescr /* store transmit descriptor pointer */ /*=== action specification ==============================================*/ munichctrlcfg.actionspec.in = 1; /* initialization procedure */ munichctrlcfg.actionspec.ico = 0; /* initialize channel only */ munichctrlcfg.actionspec.channelnumber = 0; /* - */ munichctrlcfg.actionspec.im = 0; /* interrupt mask */ munichctrlcfg.actionspec.res = 0; /* reset */ munichctrlcfg.actionspec.loopi = 0; /* loops for test purposes */ munichctrlcfg.actionspec.loop = 0; /* loops for test purposes */ munichctrlcfg.actionspec.loc = 0; /* loops for test purposes */ munichctrlcfg.actionspec.ia = 1; /* interrupt attention */ munichctrlcfg.actionspec.pcm = 5; /* pcm, cept 32 channel */ munichctrlcfg.actionspec.mfl = 256;/* maximum frame length */ /*=== interrupt queue specification =====================================*/ /* interrupt queue address */ munichctrlcfg.intqueuespec.addr = &munichintqueue [0]; /* interrupt queue size */ munichctrlcfg.intqueuespec.n = (int_queue_size_max / 16 -1); for ( i = 0; i < int_queue_size_max; i++ ) /* reset interrupt queue */ { munichintqueue[i].intflag = clear; }
peb 20320 appendix user ? s manual 250 01.2000 /*=== timeslot assignment ===============================================*/ for ( i = 0; i < 32; i++) { /* for all timeslots */ munichctrlcfg.timeslot[i].rcchannelnumber = 0; /* assigned to */ munichctrlcfg.timeslot[i].txchannelnumber = 0; /* channel 0 */ munichctrlcfg.timeslot[i].rcfillmask = 0xff;/* all bits assigned */ munichctrlcfg.timeslot[i].txfillmask = 0xff;/* per channel */ munichctrlcfg.timeslot[i].tti = 0; /* tx output active */ munichctrlcfg.timeslot[i].rti = 0; /* rc input active */ } /*=== channel specification =============================================*/ munichctrlcfg.channelspec[channel0].intmask = 0; /* interrupts enabled */ munichctrlcfg.channelspec[channel0].nitbs = 1; /* new itbs value */ munichctrlcfg.channelspec[channel0].to = 0; /* transmit */ munichctrlcfg.channelspec[channel0].ta = 1; /* initialization */ munichctrlcfg.channelspec[channel0].ti = 1; /* */ munichctrlcfg.channelspec[channel0].ro = 0; /* receive */ munichctrlcfg.channelspec[channel0].ra = 1; /* initialization */ munichctrlcfg.channelspec[channel0].ri = 1; /* */ munichctrlcfg.channelspec[channel0].th = 0; /* no transmit hold */ munichctrlcfg.channelspec[channel0].fa = 0; /* no flag adjustment */ munichctrlcfg.channelspec[channel0].tflag = 0; /* only for tma */ munichctrlcfg.channelspec[channel0].tflagcs = 0; /* crc select */ munichctrlcfg.channelspec[channel0].inv = 0; /* no bit inversion */ munichctrlcfg.channelspec[channel0].crc = 0; /* 16-bit crc */ munichctrlcfg.channelspec[channel0].trv = 0; /* transmission rate */ munichctrlcfg.channelspec[channel0].mode = 3; /* hdlc mode */ munichctrlcfg.channelspec[channel0].iftf = 0; /* idle code flags */ munichctrlcfg.channelspec[channel0].itbs = 9; /* transmit buffer size */ munichctrlcfg.channelspec[channel0].ftda = txdescr; /* first transmit */ /* descriptor address */
peb 20320 appendix user ? s manual 251 01.2000 /*=== transmit descriptor ===============================================*/ /* the next pointer of the last txdescr points to the zero pointer */ for ( ; txdescr ->next; txdescr = txdescr ->next ) { txdescr ->fnum = 3; /* 3 interframe timefill char */ txdescr ->hold = 0; /* clear hold bit */ txdescr ->hi = 0; /* clear host initiated interrupt bit */ txdescr ->fe = 0; /* clear frame end bit */ txdescr ->v110 = 0; /* clear v110 bit */ } txdescr ->fe = 1; /* set frame end bit */ txdescr ->hold = 1; /* set hold bit */ /*=== receive descriptor ================================================*/ rcdescr = allocreceivedescriptor(10); /* alloc e.g. ten */ /* receive descriptors */ /* with 32 data byte each */ munichctrlcfg.channelspec[channel0].frda = rcdescr; /* first receive */ /* descriptor address */ /*=== prepare receive descriptor 1 to 9 =================================*/ for ( ; rcdescr ->next; rcdescr = rcdescr ->next ) { rcdescr ->hold = 0; /* not the last descriptor */ rcdescr ->hi = 0; /* no host interrupt */ rcdescr ->no = 32; /* 32 data byte available */ rcdescr ->fe = 0; /* clear frame end bit */ rcdescr ->c = 0; /* clear data section complete bit */ } /*=== prepare the last receive descriptor, number 10 ====================*/ rcdescr ->hold = 1; /* last available descriptor */ rcdescr ->hi = 1; /* no host interrupt */ rcdescr ->no = 32; /* 32 data byte available */ rcdescr ->fe = 0; /* clear frame end bit */ rcdescr ->c = 0; /* clear data section complete bit */ channelcontrol[0].lasttxdescr = txdescr; /* store last transmit pointer */ channelcontrol[0].lastrcdescr = rcdescr; /* store last receive pointer */ munich32_action_request (); /* generate munich32 activation request */ }
peb 20320 appendix user ? s manual 252 01.2000 /*-------------------------------------------------------------------------- - function : txhdlcframe - -------------------------------------------------------------------------- - description : transmit an hdlc frame via channel 0 - -------------------------------------------------------------------------- */ static void txhdlcframe ( munich_tx_descr_ptr m32txdescr ) { .. .. /* ------------------------------------------------------------------------- */ m32txdescr = txdescr; /* store transmit descriptor pointer */ channelcontrol[0].lasttxdescr ->next = txdescr; /* add frame to existing */ /* channel0 frame queue */ /*=== transmit descriptor ===============================================*/ for ( ; txdescr ->next; txdescr = txdescr ->next ) { txdescr ->fnum = 3; /* 3 interframe timefill char */ txdescr ->hold = 0; /* clear hold bit */ txdescr ->hi = 0; /* clear host initiated interrupt bit */ txdescr ->fe = 0; /* clear frame end bit */ txdescr ->v110 = 0; /* clear v110 bit */ } txdescr ->fe = 1; /* set frame end bit */ txdescr ->hold = 1; /* set hold bit */ channelcontrol[0].lasttxdescr ->hold = 0; /* the polling munich32 */ /* will then detect the */ /* cleared hold bit and */ /* send the following */ /* frame */ channelcontrol[0].lasttxdescr = txdescr; /* store last transmit pointer */ }

▲Up To Search▲

Price & Availability of PEB20320

	To Download PEB20320 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .